Am 07.07.2010 um 15:21 schrieb Thiago H. de Paula Figueiredo:
> On Wed, 07 Jul 2010 08:58:51 -0300, Christian Riedel
> <[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
