tapestry-dev mailing list archives

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

Am 07.07.2010 um 15:21 schrieb Thiago H. de Paula Figueiredo:

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

Of course, I have to call both methods and see whether the result is null or not. For rewritten
incoming requests both decoders will return null as the page name is not known to tapestry:

        if (!componentClassResolver.isPageName(pageName))
            return null;

So in the end I have to parse it by myself again, right? Maybe we just need a thin layer around
PageRenderRequestParameters and ComponentEventRequestParameters that would resolve getPageName()
by also looking into contributed URLRewriting rules.
Or the ComponentClassResolver returns true for the rewritten page name... I don't know what
would be best :)


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

Nice idea, as the ComponentSource provides methods for retrieving pagename and component id...


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

But I know that Howard is integrating lots of features into Tapestry that were kind of requirements
of his customers, so why not have some other's, too ;)



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


Mime
View raw message