tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Stärk <...@spielviel.de>
Subject Re: New Link Rewriting code (TAP5-954, TAP5-1042)
Date Wed, 02 Jun 2010 17:33:19 GMT
I completely agree.

On 02.06.2010 19:31, Robert Zeigler wrote:
> In theory, it seems like this should be possible.  Given how HLS has described the new
system, the two systems should be orthogonal.
> It would be ugly, though, to have two systems.  Still, I'm personally +1 in keeping the
existing URLRewriting system, but deprecating for the 5.2-series release, and then removing
it altogether in 5.3.
> That would ease the barrier to upgrade, and give users time to play with the new system
before yanking the old one out from under their feet. That would be my preferred approach.
>
> Robert
>
> On Jun 2, 2010, at 6/212:16 PM , Igor Drobiazko wrote:
>
>> Is it possible to deprecate the existing code without to remove it?
>>
>> On Wed, Jun 2, 2010 at 7:11 PM, Howard Lewis Ship<hlship@gmail.com>  wrote:
>>
>>> I'm starting work on a replacement for the URLRewriter system.  We've
>>> previously discussed this, and it will be a non-backwards compatible
>>> change (I'm starting by removing the existing URLRewriter and related
>>> code).
>>>
>>> The goals are:
>>>
>>> * Keep it simple.
>>> * Make it possible to easily rewrite the Links created for component
>>> event requests, page render requests, and asset requests.
>>>
>>> I think the basic API will be something like:
>>>
>>> public interface ComponentEventLinkTransformer {
>>> Link transformComponentEventLink(Link link,
>>> ComponentEventRequestParameters parameters);
>>> }
>>>
>>> In other words, contributed code has access to the same information as
>>> the ComponentEventLinkEncoder service (in fact, this will be invoked
>>> from inside CELE). There will be an ordered configuratoin
>>> of transformers.  A transformer can return a non-null Link to replace
>>> the default Link.
>>>
>>> I have two main use cases:
>>>
>>> One client wants to easily prefix all Tapestry requests with the
>>> virtual folder "t5"  (i.e., "/t5/somepage") to make it easier to run
>>> the T4 and T5 versions of the application side-by-side.
>>>
>>> A second client wants some specific control over URLs. They want a
>>> certain page to have a number of URLs that would normally map to the
>>> Index page instead map to this alternate page, with context.
>>> Obfuscated example: they want "/toys", "/games", and "/equipment" to
>>> all point to a Search page, each with a different page activation
>>> context.  The short URL is important to them, but there's already an
>>> Index page at "/".
>>>
>>>
>>> --
>>> 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: dev-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de/blog
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>

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


Mime
View raw message