tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thiago H. de Paula Figueiredo" <thiag...@gmail.com>
Subject Re: URL Rewriting in Tapestry 5.2
Date Wed, 07 Jul 2010 13:21:43 GMT
On Wed, 07 Jul 2010 08:58:51 -0300, Christian Riedel  
<cr.mlist@googlemail.com> wrote:

> Hi,
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...

I'm not following you. Just inject ComponentEventLinkEncoder and use its  
decoder methods.

> 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}"));

This looks like it's better implemented as a ComponentSource advice.

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

You can do this on the top of 5.1 URL rewriting easily. There are many  
improvements that can be made, of course.

> 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.

Don't forget you can override Tapestry services and that you requirements  
can be too specific to be on Tapestry itself. ;)

-- 
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,  
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

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


Mime
View raw message