[prev in list] [next in list] [prev in thread] [next in thread] 

List:       tapestry-user
Subject:    RE: T5.1 URL Rewriting
From:       "Blower, Andy" <Andy.Blower () proquest ! co ! uk>
Date:       2009-03-31 16:30:12
Message-ID: F322F8D64BAD61459427B12F0E6AE22EA867A65060 () CBGPQMAILBX01V ! proque ! st
[Download RAW message or body]

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:levi@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-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 



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


[prev in list] [next in list] [prev in thread] [next in thread]