The path optimizer isn't working properly with rewritten paths anyway (at least in 5.1, you fixed that for 5.2, right?) Maybe the other way round is better: add the locale to the incoming path as soon as the localization setter sets it. I tried it this way in a big application for a client and it works fine! Of course if you change the path during the master dispatcher's phase it wouldn't work out...
Am 07.07.2010 um 20:57 schrieb Howard Lewis Ship: > 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] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
