Howard Lewis Ship schrieb:
Good points. There are two conflicting demands from the community:
First, that everything should work, and work well (and fast) out of
the box.  Second, that everything be customizable.

When resolving such conflicts, I will tend to favor the first (work
and work well with no configuration) over the second.

That being said, it would be nice if we could handle a few of these
cases better or easier: for example, something more automatic in terms
of detecting a 404 inside the Index page's activation context, or some
other mechanism to easily distinguish proper page render requests
(with context) from link garbage.



Please don't get me wrong. I totally agree with your point that "First, that everything should work".




On Thu, Jul 9, 2009 at 3:52 PM, Andy Pahne<andy.pa...@googlemail.com> wrote:
Just a few finding while doing SEO for a t5 app:



1. activation context and Index pages

The root Index page of the t5 webapp catches a lot of requests that
otherwise would have been a 404. (already discussed on the list).

For our website that means: there are many pages in the google index that
have gone a long time ago. But because T5 simply activates the root Index
page for those google spider requests, google now finds the start page and
reindexes the gone page with the homepage contents. Not quite lucky.

Quick workaround: check the root Index page's activation context:

  Object onActivate(EventContext ctx){
             if(ctx.getCount() == 0)
          return null;
       // handle bad requests,
       return Document404.class;   // does the "not found" details
  }




2. Pages with .php extensions

Our public website was a PHP application before we replaced it with our new
shiny t5 app. So google had a lot of URLs like  .../index.php?id=222 in it's
index.

When we switched to t5 and google respidered our website, those requests
failed instead of a proper 404 was thrown. Why? Because our Index page did
not contain a component named "php"

Quick workaround:
  Object onActionFromPhp() {
      return Fehler404.class;
  }




3. Lowercasing of Page Names

When T5 redirects, page names, component names (, ...?) all become
lowercase. I wish that T5 in it's default settings would preserve the case
used in originating URLs

Does this actually affect SEO?

No, I don't think so. Just a matter of personal preference.
4. I wish, T5 would allow underscores, so that my page named "DailyEvents"
could have a URL like daily_events


As we add more and more and more of these special cases, it gets
harder and harder to talk authoritatively about what Tapestry will do,
and it becomes increasingly impossible for 3rd party tools (such as
IDE plugins) to operate.  Name your class Daily_Events.



Sounds reasonable. I didn't even think about third party tools at first.


5. I wish that T5 in it's default setting would allow   daily_events.html in
it's default settings as page name for the same page as in the example
above.

This is frequently requested ... is there a JIRA issue for it (hint)?


https://issues.apache.org/jira/browse/TAP5-771





I know that T5 URL handling is highly customizable. I wish I had the time to
look into that.

Well, if SEO is that important to your bottom line, you probably should.



Sooner or later I'll will. Unfortunatly my workload doesn't allow it right now.



What do you think? Or do you have other findings with regards to SEO?


Andy



So far, my contacts who do SEO are quite happy with Tapestry, though
they created an override to hack ".html" into the URLs.


As I said: There are quite easy workaround for most of these points. And in your answer you suggested even more...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to