tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Riedel <cr.ml...@googlemail.com>
Subject URL Rewriting in Tapestry 5.2
Date Wed, 07 Jul 2010 11:58:51 GMT

is the current replacement of the URLRewriter (LinkTransformer) the final new API for url-rewriting?

I would find some missing things quite useful:

1. A service that parses the request path. 
In 5.1 I found it frustrating that there was no proper API within Tapestry to read out the
locale (in an early stage of request processing), the page name and wether it's a component
request or not. The ComponentEventLinkEncoderImpl does lots of parsing to find out all of
these information but it doesn't share them. So to get the same information you'd have to
use the same code somehow...

2. Mapping of rewrite rules.
Other frameworks have some point where the user may configure a regex and provide a rewritten
path. Wouldn't it be nice if there would be some URLRewritingSource service that one could
contribute these mappings to?

configuration.add("foo", new URLMapper("someregex", "${message:localizedPageName}"));

Anything different from reinventing the wheel with each application you develop would be great

3. Setting the locale according to the incoming request path.
Again, the ComponentEventLinkEncoderImpl provides a very important feature that is hard to
modify. I've had the requirement to change the localization of the page according to the language
of the request path. I don't mean the /en/ persistent local thing, I mean a request path like
/home and /accueil or similar. The page's name can be found in a specific translation's resource
bundle. In 5.1, I rewrote the request path to /en/home or /fr/accueil or similar. Then ComponentEventLinkEncoderImpl
would read out the locale from the path correctly... 
However, if I would just set the persistent locale by myself and leave the request path ComponentEventLinkEncoderImpl
tries to resolve /home as a locale, fails and sets some default locale that it's got from
the thread or the request.
An extension to the LocalizationSetter could solve this maybe.

Well, I hope my thoughts on that are not too far away from what you think Tapestry-Core should
contain :)

To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org

View raw message