tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: URL Rewriting in Tapestry 5.2
Date Wed, 07 Jul 2010 18:57:43 GMT
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
<cr.mlist@googlemail.com> wrote:
> Hi,
> is the current replacement of the URLRewriter (LinkTransformer) the final new API for
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org

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

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

View raw message