I've been rapidly closing the gap between where Tapestry 5 is and where it needs to be for a stable release.
Today I added in index pages; literally, pages named Index.
In the past, you could create a Start page and it would be used for any request that just specified the servlet context but didn't identify a specific page. That was great ... at the top level. It's also supported for backwards compatibility (even I am not that cruel).
However, the preferred method is to call that page Index. Further, you can place Index pages in subfolders as well. Tapestry can reference such a page using just the folder name.
That's great so far, but nobody wants to have a bunch of classes with the same name, even in different folders. No problem; the standard "name stripping" occurs. Thus, you might have an ecommerce application and three pages : com.myco.pages.order.OrderIndex, com.myco.pages.order.OrderVerify and com.myco.pages.order.OrderSubmit. The names of these three pages will be "order/Index", "order/Submit" and "order/Verify" (the redundant parts are stripped out). Lastly, Tapestry will create URLs of the form ".../context/order", ".../context/order/submit" and ".../context/order/verify".
In other words, short, sensible URLs and no compromises in your code. And, as always, any extra path info beyond the page name is treated as page activation context, made available to the page via the "activate" event handler method.
I'm very happy with this change; I also think Tapestry's built-in rules for URLs are really strong and appealing; I simply don't see customizing the built-in rules to be a priority, or frankly, of any great value.
13 comments:
I also think Tapestry's built-in rules for URLs are really strong and appealing; I simply don't see customizing the built-in rules to be a priority, or frankly, of any great value.
Huh! This is a great mistake! I do see a great value of it:
- adapt to "legacy" URLs. If all the search engines do have thousands of your pages indexed, you cannot change suddently all the URLs just because you change the technology.
- secondly and maybe more importantly, *search engines*.
With tapestry 4 we did lot of tweaking for search engine ranking. For instance, instead of /products/itempage?ref=MYREF
you rather want /product/product-description/more-keywords/productref or something like that. If this ability is not in T5, T5 might be burned for many internet websites.
A mistake indeed. The ability to customize the URL is of great value in T4 and we use it quite heavily.
you still have the ability to do some url-rewriting or mapping in your webserver, but i think that custom urls are of great value for every online marketeer.
Cool URIs don't change
http://www.w3.org/Provider/Style/URI
sounds great Howard... totally makes sense. I would agree with hdupre that there is always some benefit to leaving the system open to alternate URL mapping schemes, but I wouldn't lose sleep over it. Keep up the good work on T5... it made our latest project such a joy to develop!
I agree that the T5 url's are way better than before, but i think that should have some effort on customizing them... Although they're more legible, "bookmarkable" and logic than in T4, some people may want to change them on it's very own way
Hello,
I agree 10000% with Henry. If you cannot customise the URL with some keywords useful for page ranking in search engines, that's pretty bad. Tap 4 allows you to do that and it is a great feature. It is a 'must have' feature if you need to develop e-commerce or public website.
Great work ...
Nums
Thanks Howard for the index pages! I've been needing something like this for a while.
Regarding asking for search-engine-friendly URLs, am I missing something? URL's like /product/product-description/more-keywords/productref are just the "Project.java" page, with a 3-value context parameter, right? It seems like T5 already does this, and does it well.
Legacy URLs are a different beast, but J2EE ServletFilters may already be the "right" technology for writing URL mappers.
I'm glad someone besides me agrees about the URLs ... and the use of the page activation context to keep search engines happy. Personally, I think that is a risky strategy on two fronts. First, the URL will contain production description and other variable content; you are stuffing mutable data into something that is supposed to be immutable and eternal. As Albert pointed out, cool URIs don't change.
Second; what happens when the search engines change strategies and all that cruft in the URL is counted against your ranking instead of for it?
I'm completely lost Howard.
What does your reply mean for me who likes the fact that we can customize the URLs in T4 nowadays. Will this be possible in T5 or not? I like REST style URLs we can create in T4.
.../products/product/10
what happens when the search engines change strategies and all that cruft in the URL is counted against your ranking instead of for it?
Straigh simple, change the URLs. You may not have an idea how important this can be. The URLs = traffic and $$ directly.
How customizable is the page activation context?
Here's the deal; if I was building a ViewProduct page, it might look like:
public class ViewProduct
{
@GenerateAccessors
private Product _product;
Object onPassivate()
{
return _product;
}
void onActivate(Product product)
{
_product = product;
}
}
(This assumes some setup to provide a ValueEncoder for Product so that the Product is represented in the URL as the product id).
For your page ranking purposes, you might instead:
public class ViewProduct
{
@GenerateAccessors
private Product _product;
Object onPassivate()
{
return new Object[] {
_product.getCategory(),
_product.getDescription(),
_product.getKeywords(),
_product };
}
void onActivate(String category, String description, String keyword, Product product)
{
_product = product;
}
}
What if my application is in a different language other than english, and I would like my index pages to use a different word other than "start" or "index"? (Like "kwanza")
Otherwise, great job Howard.
Post a Comment