I realize that these are fairly intertwined in the code-base, but is
there any way we can abstract these out into their own projects? It
would be good, then, to be able to simply leave off the one you don't
want, or keep both, but the mechanism would be external, and
documented properly as a separate subsystem. Might make this sort of
transition easier if it were first pulled out.
Christian.
On Jun 2, 2010, at 1:31 PM, 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
<[email protected]> 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: [email protected]
For additional commands, e-mail: [email protected]
--
Best regards,
Igor Drobiazko
http://tapestry5.de/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
