I've hit some issues related to the introduction of the locale. I'm thinking about how this could be resolved. The problem is, if we strip off the locale earlier (providing a new Request object with a changed result from getPath()), before the MasterDispatcher, it can confuse some of the other logic (particularly, the code that optimizes URLs for the current page).
On Wed, Jul 7, 2010 at 4:58 AM, Christian Riedel <[email protected]> wrote: > Hi, > > 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 :) > > Cheers, > Christian > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
