If you want to stay away from extending the internals then a decorator / advisor of the ComponentEventLinkEncoder service would be the best route, as Thiago suggested. You will still have a reference to LinkImpl which is an internal implementation since you'll need to create a new link. I don't want to duplicate all the processing in ComponentEventLinkEncoderImpl so I will extend and change it, but it's much better than my 5.0 version because it's all in one place and the service interface is public this time.
> -----Original Message----- > From: xfile80303 [mailto:l...@grokers.net] > Sent: 31 March 2009 17:19 > To: users@tapestry.apache.org > Subject: RE: T5.1 URL Rewriting > > > > > Hey Levi, > > That's almost identical to what I need for my application. Sorry I > missed your post back in Feb, I had a two week holiday mid feb so I > wasn't following. You did this the same way as me by creating your own > PageRenderDispatcher and LinkFactory. My scenario is possibly a little > more complex because if there's a T5 page at /SITE/page then it uses > that, if not and SITE is recognised as a configured site then it's > moved to the end of the URL. (becoming the last context param) > > I'm now migrating to T5.1.0.2 and looking at how I should implement > this now. That's why I was looking at URL rewriting to see if it was > appropriate for this task in 5.1 - I wasn't looking at the nightly docs > though. Now I am and I can see what Thiago means but I don't think URL > rewriting is the right place to do this. I'm leaning towards a custom > implementation of ComponentEventLinkEncoder (possibly extending the > internal T5.1 impl) since the URL analysis which is going on in here is > what I need to figure out what (if anything) needs doing to the URL. > > Are there any other ways of doing this, and is this the best? Opinions > welcome. > > Thanks, > Andy. > > > Hi Andy, > > It certainly looks like we have similar ideas to re-solve with > 5.1.0.n>1. ;) > > I'm in the midst of trying to understand the best approach to this > myself, and would like to stay away from extending Tapestry internals > or other "hacks" like I did previously so upgrading in the future does > not break my app, etc. However, it may be that even the most recent > code is not capable of being used in a way that can accomplish our > goals without resorting to touching the internals. > > I'll post back what my solution turns out to be. > > Best of luck, > > Levi > -- > View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting- > tp2557652p2563958.html > Sent from the Tapestry Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org