You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by "Blower, Andy" <An...@proquest.co.uk> on 2009/03/30 16:49:59 UTC
T5.1 URL Rewriting
This is largely a question for Thiago, but feel free to chime in if you can help...
The URL Rewriting feature in T5.1 was added for TAP5-577 and in the comments Thiago said "Each rule will be applied, but each one can decide to really rewrite the URL/link or not. If you take a look at the tests (app5.services.AppModule), you see rules that only apply to incoming URL requests and ignore the others and rules that only apply only for generated links. And there is even one rule that applies to a single URL."
I've just been looking at the tests and I can't see any rules that will apply only to generated or incoming links. What am I missing? Can anyone clue me in?
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
On Mar 30, 2009, at 3/304:47 PM , xfile80303 wrote:
>
>> Is there a way to utilize this to only rewrite page render requests
>> and
>> not component or asset requests? I know it is pretty early on in the
>> request lifespan, but without this discrimination this feature is not
>> nearly as useful to me (and possibly others?).
>
> It's really very early in the request handling pipeline. Maybe
> Tapestry
> should add some way (maybe methods in the Request instance) that
> tells if
> the given request is an page one or an event one or an asset one or
> etc.
>
-1. Although there are times when I've thought this might be handy,
the determination of the request type is resolved via the
MasterDispatcher service; if you really need to know the request type,
then the operation you're performing probably needs to come later in
the flow of operations.
Robert
Hi Robert, I don't actually need to know the request type /if/ I can implement bi-directional URL re-writing, as discussed. However, you may have a point... the URL Rewriting implementation here is so low level as to be limited in usefulness when dealing with internal Tapestry concepts and conveniences. If I use the URL Rewrite implementation I will need to re-implement a lot of the code Tapestry uses internally to determine page, locale, etc.
Levi
Hi Robert,
In looking at this further I think the only thing I need that Tapestry would normally provide is the Locale, and I am comfortable parsing the URL for that myself. So I'd like to proceed with the URL Rewriting approach discussed here. Is this something you (all) can/will implement relatively soon?
Cheers!
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2570690.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
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
On Mar 30, 2009, at 3/304:47 PM , xfile80303 wrote:
>
>> Is there a way to utilize this to only rewrite page render requests
>> and
>> not component or asset requests? I know it is pretty early on in the
>> request lifespan, but without this discrimination this feature is not
>> nearly as useful to me (and possibly others?).
>
> It's really very early in the request handling pipeline. Maybe
> Tapestry
> should add some way (maybe methods in the Request instance) that
> tells if
> the given request is an page one or an event one or an asset one or
> etc.
>
-1. Although there are times when I've thought this might be handy,
the determination of the request type is resolved via the
MasterDispatcher service; if you really need to know the request type,
then the operation you're performing probably needs to come later in
the flow of operations.
Robert
Hi Robert, I don't actually need to know the request type /if/ I can implement bi-directional URL re-writing, as discussed. However, you may have a point... the URL Rewriting implementation here is so low level as to be limited in usefulness when dealing with internal Tapestry concepts and conveniences. If I use the URL Rewrite implementation I will need to re-implement a lot of the code Tapestry uses internally to determine page, locale, etc.
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2563933.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
Re: T5.1 URL Rewriting
Posted by Robert Zeigler <ro...@scazdl.org>.
On Mar 30, 2009, at 3/304:47 PM , xfile80303 wrote:
>
>> Is there a way to utilize this to only rewrite page render requests
>> and
>> not component or asset requests? I know it is pretty early on in the
>> request lifespan, but without this discrimination this feature is not
>> nearly as useful to me (and possibly others?).
>
> It's really very early in the request handling pipeline. Maybe
> Tapestry
> should add some way (maybe methods in the Request instance) that
> tells if
> the given request is an page one or an event one or an asset one or
> etc.
>
-1. Although there are times when I've thought this might be handy,
the determination of the request type is resolved via the
MasterDispatcher service; if you really need to know the request type,
then the operation you're performing probably needs to come later in
the flow of operations.
Robert
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5.1 URL Rewriting
Posted by "Blower, Andy" <An...@proquest.co.uk>.
> > 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.
>
> As Fernando Padilla would point out and I would agree 100% :),
> decorating services is almost always a good option. In this specific
> case, you would need to change the Link instances returned by
> ComponentEventLink methods, something that the URL rewriting support
> already does.
I can see how that would work, but as I said I'd be repeating a fair bit of the URL analysis that the ComponentEventLinkEncoder is already doing which is why I'm not planning to decorate, advise or rewrite for my use case. Thanks for the help anyway Thiago.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Mar 31, 2009 at 6:26 AM, Blower, Andy
<An...@proquest.co.uk> wrote:
> 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 don't think I said that. :)
> 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.
As Fernando Padilla would point out and I would agree 100% :),
decorating services is almost always a good option. In this specific
case, you would need to change the Link instances returned by
ComponentEventLink methods, something that the URL rewriting support
already does.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Apr 7, 2009 at 6:27 AM, Blower, Andy <An...@proquest.co.uk> wrote:
> I just want to post an update to this. When I started to do this work I realised that I was not going to duplicate much processing from
> ComponentEventLinkEncoderImpl if I used method advice - so that's what I've done. This is much nicer way of doing things and came at a much lower
> efficiency hit than I first thought it would.
Service decoration rules!
> The URL rewriting code was helpful as an example of creating a new LinkImpl - I would not have noticed so quickly that the optimizer was not necessary for
> the new Link because it will already have done its job.
The beauty of open source . . . you can always learn a lot reading the
sources . . . :)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5.1 URL Rewriting
Posted by "Blower, Andy" <An...@proquest.co.uk>.
I just want to post an update to this. When I started to do this work I realised that I was not going to duplicate much processing from ComponentEventLinkEncoderImpl if I used method advice - so that's what I've done. This is much nicer way of doing things and came at a much lower efficiency hit than I first thought it would.
The URL rewriting code was helpful as an example of creating a new LinkImpl - I would not have noticed so quickly that the optimizer was not necessary for the new Link because it will already have done its job.
> -----Original Message-----
> From: Blower, Andy [mailto:Andy.Blower@proquest.co.uk]
> Sent: 31 March 2009 17:30
> To: 'Tapestry users'
> Subject: RE: T5.1 URL Rewriting
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
RE: T5.1 URL Rewriting
Posted by "Blower, Andy" <An...@proquest.co.uk>.
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
RE: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
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
RE: T5.1 URL Rewriting
Posted by "Blower, Andy" <An...@proquest.co.uk>.
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.
> -----Original Message-----
> From: xfile80303 [mailto:levi@grokers.net]
> Sent: 30 March 2009 23:28
> To: users@tapestry.apache.org
> Subject: Re: T5.1 URL Rewriting
>
> Perhaps a better example is needed...
>
> I want to insert the notion of "site" into the URL and application,
> such that I can use the same pages to render content, but these pages
> can have access to what "site" they are currently rendering and change
> behavior, look and feel, whatever. The site parameter would need to be
> available for all pages, not just a page context parameter, so the
> application url looks something like:
>
> http://myhost.com/SITE/page/params
>
> Where the only difference from normal Tapestry URL is the insertion of
> the SITE before the rest of the URI, such that SITE could be anything
> (like, "partner", "foo", or "main" etc.).
>
> So the URL Rewriting implementation does not seem to be quite a match
> since if I insert anything for SITE, as mentioned, it breaks Tapestry's
> ability to properly deal with the request for pages and page content,
> etc. The SITE parameter needs to be "virtual" and yet still generated
> for page links.
>
> Not to cloud the issue, but for reference:
>
> http://n2.nabble.com/-T5--Struggling-With-Concepts-tt2324920.html
> http://n2.nabble.com/-T5--URL-Manipulation-tt2276010.html
>
> Since those posts I was able to create a dispatcher which replaced the
> PageRender dispatcher and a LinkFactory which overrides the
> createPageRenderLink functionality to insert the "site" parameter into
> the generated URLs.
>
> Since 5.1.0.0 there seems to have been a lot of work in this space
> (which is great!) and I was hoping to avoid overriding internal
> functionality in order to accomplish what I needed (and allow for a
> simpler upgrade path in the future).
>
> Thanks,
>
> Levi
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Mar 31, 2009 at 11:53 AM, Thiago H. de Paula Figueiredo
<th...@gmail.com> wrote:
> On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
>> Another option would be to combine the URLRewriterRule with an enum to
>> define when it is in effect (INCOMING, OUTGOING, BOTH).
>
> I still prefer the context parameter option, so it can differentiate
> page links from action links.
Thinking it over, both approaches can be combine so a rule process()
method wouldn't be invoked for an incoming URL when it doesn't rewrite
them, for example.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship <hl...@gmail.com> wrote:
> Another option would be to combine the URLRewriterRule with an enum to
> define when it is in effect (INCOMING, OUTGOING, BOTH).
I still prefer the context parameter option, so it can differentiate
page links from action links.
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by Howard Lewis Ship <hl...@gmail.com>.
Another option would be to combine the URLRewriterRule with an enum to
define when it is in effect (INCOMING, OUTGOING, BOTH).
On Mon, Mar 30, 2009 at 8:43 PM, Robert Zeigler <ro...@scazdl.org> wrote:
> Yeah, I definitely think there needs to be at least /some/ disambiguation
> between request and response.
> A number of ways we could do that:
> 1) Have two separate services, one for incoming, one for outgoing
> * Not a fan; adds an additional contribution point/burden
> 2) Have two different "process" methods: processIncoming and processOutgoing
> (processRequest, processResponse?)
> * Clean, I think...
> 3) Have some sort of context passed to "process" that can be used to query
> the state.
> * ambivalent about this approach.
>
> Without having looked over the urlrewriting code, I'm leaning toward
> approach #2. I'd be interested in hearing your feedback, Thiago. I might
> have a few spare cycles this week that I can use to implement this change...
>
> Robert
>
> On Mar 30, 2009, at 3/306:12 PM , xfile80303 wrote:
>
>>
>>
>>
>> Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 <le...@grokers.net>
>> escreveu:
>>
>>> Okay this sounds like a plausible approach, but I'm confused about how I
>>> would identify the fact that my filter is being called to handle an
>>> incoming request (and remove the SITE) or a link generation request (and
>>> insert the site).
>>
>> That's a concrete reason to add some differentiation between incoming URL
>> rewriting and link rewriting. I'll implement it as soon as I can.
>>
>>
>> Thanks Thiago, that would be most appreciated!
>>
>> Levi
>> --
>> View this message in context:
>> http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2560206.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
>
>
--
Howard M. Lewis Ship
Creator Apache Tapestry and Apache HiveMind
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
On Tue, Mar 31, 2009 at 1:21 AM, Robert Zeigler <ro...@scazdl.org> wrote:
> As a sort of nitpicky aside... does URLRewriterService have to be called
> that? (Since we're still in new feature api-change mode, here... :).
> What about just URLRewriter? Or URLRewriteHandler? Either of those seem to
> gel a little more with existing naming (plus we then don't have the
> redundancy of org.apache.tapestry5.*services*.URLRewriter*Service* (with *
> added for emphasis).
I agree with you. As you're implementing this improvement, don't
forget to update the documentation. ;) And thank you for implementing
this, as I unfortunately cannot do this now. :)
--
Thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Just a suggestion: please quote the messages you're answering with >.
Without them, it's hard to figure out what's the answer and what's being
answered. ;)
Hi Thiago,
I'm just using nabble.com to access and post to this list and the quoting features of nabble. Perhaps try viewing your email as HTML or using nabble too?
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2563802.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 20:12:30 -0300, xfile80303 <le...@grokers.net> escreveu:
> Thanks Thiago, that would be most appreciated!
Unfortunately, I don't know when I can do that.
Just a suggestion: please quote the messages you're answering with >.
Without them, it's hard to figure out what's the answer and what's being
answered. ;)
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by Robert Zeigler <ro...@scazdl.org>.
As a sort of nitpicky aside... does URLRewriterService have to be
called that? (Since we're still in new feature api-change mode,
here... :).
What about just URLRewriter? Or URLRewriteHandler? Either of those
seem to gel a little more with existing naming (plus we then don't
have the redundancy of
org.apache.tapestry5.*services*.URLRewriter*Service* (with * added for
emphasis).
Just a thought...
Robert
On Mar 30, 2009, at 3/3010:52 PM , Thiago H. de Paula Figueiredo wrote:
> Robert, nice suggestions. My idea was to add to to add two methods
> to URLRewriterRule, boolean rewritesInboundURLs() and
> rewritesOutboundURLs() (or any other better name, suggestions
> welcome) to URLRewriterRule and then change the internal services
> implementation accordingly.
>
> --
> Thiago H. de Paula Figueiredo
> Independent Java consultant, developer, and instructor
> http://www.arsmachina.com.br/thiago
>
> ---------------------------------------------------------------------
> 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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Robert, nice suggestions. My idea was to add to to add two methods to
URLRewriterRule, boolean rewritesInboundURLs() and rewritesOutboundURLs()
(or any other better name, suggestions welcome) to URLRewriterRule and
then change the internal services implementation accordingly.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by Robert Zeigler <ro...@scazdl.org>.
Yeah, I definitely think there needs to be at least /some/
disambiguation between request and response.
A number of ways we could do that:
1) Have two separate services, one for incoming, one for outgoing
* Not a fan; adds an additional contribution point/burden
2) Have two different "process" methods: processIncoming and
processOutgoing (processRequest, processResponse?)
* Clean, I think...
3) Have some sort of context passed to "process" that can be used to
query the state.
* ambivalent about this approach.
Without having looked over the urlrewriting code, I'm leaning toward
approach #2. I'd be interested in hearing your feedback, Thiago. I
might have a few spare cycles this week that I can use to implement
this change...
Robert
On Mar 30, 2009, at 3/306:12 PM , xfile80303 wrote:
>
>
>
> Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 <le...@grokers.net>
> escreveu:
>
>> Okay this sounds like a plausible approach, but I'm confused about
>> how I
>> would identify the fact that my filter is being called to handle an
>> incoming request (and remove the SITE) or a link generation request
>> (and
>> insert the site).
>
> That's a concrete reason to add some differentiation between
> incoming URL
> rewriting and link rewriting. I'll implement it as soon as I can.
>
>
> Thanks Thiago, that would be most appreciated!
>
> Levi
> --
> View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2560206.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
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 <le...@grokers.net> escreveu:
> Okay this sounds like a plausible approach, but I'm confused about how I
> would identify the fact that my filter is being called to handle an
> incoming request (and remove the SITE) or a link generation request (and
> insert the site).
That's a concrete reason to add some differentiation between incoming URL
rewriting and link rewriting. I'll implement it as soon as I can.
Thanks Thiago, that would be most appreciated!
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2560206.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 <le...@grokers.net> escreveu:
> Okay this sounds like a plausible approach, but I'm confused about how I
> would identify the fact that my filter is being called to handle an
> incoming request (and remove the SITE) or a link generation request (and
> insert the site).
That's a concrete reason to add some differentiation between incoming URL
rewriting and link rewriting. I'll implement it as soon as I can.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Em Mon, 30 Mar 2009 19:28:23 -0300, xfile80303 <le...@grokers.net> escreveu:
> http://myhost.com/SITE/page/params
>
> Where the only difference from normal Tapestry URL is the insertion of
> the SITE before the rest of the URI, such that SITE could be anything
> (like, "partner", "foo", or "main" etc.).
>
> So the URL Rewriting implementation does not seem to be quite a match
> since if I insert anything for SITE, as mentioned, it breaks Tapestry's
> ability to properly deal with the request for pages and page content,
Have you tested this? I don't think it will break Tapestry, as it would
only see requests for http://myhost.com/page/params.
Yes, I have, but I was inserting the SITE value into the request URL which is what does the breaking.
> etc. The SITE parameter needs to be "virtual" and yet still generated
> for page links.
The URL rewriting support also rewrites generated links, so all you need
here is to implement a rule that does rewrites incoming URLs to remove the
site id and rewrites generated links to include the site id. I wrote the
URL writing support a little more complicated scenario: login.domain.com
to domain.com/page/domain and vice-versa.
Okay this sounds like a plausible approach, but I'm confused about how I would identify the fact that my filter is being called to handle an incoming request (and remove the SITE) or a link generation request (and insert the site).
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2560110.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 19:28:23 -0300, xfile80303 <le...@grokers.net> escreveu:
> http://myhost.com/SITE/page/params
>
> Where the only difference from normal Tapestry URL is the insertion of
> the SITE before the rest of the URI, such that SITE could be anything
> (like, "partner", "foo", or "main" etc.).
>
> So the URL Rewriting implementation does not seem to be quite a match
> since if I insert anything for SITE, as mentioned, it breaks Tapestry's
> ability to properly deal with the request for pages and page content,
Have you tested this? I don't think it will break Tapestry, as it would
only see requests for http://myhost.com/page/params.
> etc. The SITE parameter needs to be "virtual" and yet still generated
> for page links.
The URL rewriting support also rewrites generated links, so all you need
here is to implement a rule that does rewrites incoming URLs to remove the
site id and rewrites generated links to include the site id. I wrote the
URL writing support a little more complicated scenario: login.domain.com
to domain.com/page/domain and vice-versa.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Em Mon, 30 Mar 2009 18:47:39 -0300, xfile80303 <le...@grokers.net> escreveu:
> http://n2.nabble.com/How-to-parse-and-map-URLs--tt2540788.html
Besides the .page suffix in the example (I guess it is just wront), simple
URL rewriting (i.e. changing a page name) shouldn't cause you troubles. If
I wasn't having serious 64-bit Eclipse instability on Linux now, I would
try to do some simple rewriting in a real application I'm writing now . . .
Perhaps a better example is needed...
I want to insert the notion of "site" into the URL and application, such that I can use the same pages to render content, but these pages can have access to what "site" they are currently rendering and change behavior, look and feel, whatever. The site parameter would need to be available for all pages, not just a page context parameter, so the application url looks something like:
http://myhost.com/SITE/page/params
Where the only difference from normal Tapestry URL is the insertion of the SITE before the rest of the URI, such that SITE could be anything (like, "partner", "foo", or "main" etc.).
So the URL Rewriting implementation does not seem to be quite a match since if I insert anything for SITE, as mentioned, it breaks Tapestry's ability to properly deal with the request for pages and page content, etc. The SITE parameter needs to be "virtual" and yet still generated for page links.
Not to cloud the issue, but for reference:
http://n2.nabble.com/-T5--Struggling-With-Concepts-tt2324920.html
http://n2.nabble.com/-T5--URL-Manipulation-tt2276010.html
Since those posts I was able to create a dispatcher which replaced the PageRender dispatcher and a LinkFactory which overrides the createPageRenderLink functionality to insert the "site" parameter into the generated URLs.
Since 5.1.0.0 there seems to have been a lot of work in this space (which is great!) and I was hoping to avoid overriding internal functionality in order to accomplish what I needed (and allow for a simpler upgrade path in the future).
Thanks,
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2560040.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 18:47:39 -0300, xfile80303 <le...@grokers.net> escreveu:
> http://n2.nabble.com/How-to-parse-and-map-URLs--tt2540788.html
Besides the .page suffix in the example (I guess it is just wront), simple
URL rewriting (i.e. changing a page name) shouldn't cause you troubles. If
I wasn't having serious 64-bit Eclipse instability on Linux now, I would
try to do some simple rewriting in a real application I'm writing now . . .
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Em Mon, 30 Mar 2009 18:21:14 -0300, xfile80303 <le...@grokers.net> escreveu:
> Hi Thiago, all,
Hi!
> Thanks for adding this feature.
:)
> Is there a way to utilize this to only rewrite page render requests and
> not component or asset requests? I know it is pretty early on in the
> request lifespan, but without this discrimination this feature is not
> nearly as useful to me (and possibly others?).
It's really very early in the request handling pipeline. Maybe Tapestry
should add some way (maybe methods in the Request instance) that tells if
the given request is an page one or an event one or an asset one or etc.
Don't forget that every rules can choose if it will overwrite the request
(returning another Request instance) or not, so your rule must first check
if the request is one that needs to be rewritten or not. What exactly is
the URL rewriting you want to do?
Yeah, I was afraid of this being too early on.
I understand the rules can choose to augment the request or not, but short of having my rule be smart enough to understand what type of request is potentially being re-written (which in my opinion is best left to the internals of Tapestry, as you suggest may be possible) there's no real way (that I see?) for me to accomplish something quite similar to this post:
http://n2.nabble.com/How-to-parse-and-map-URLs--tt2540788.html
without breaking all asset and component requests.
i.e. I can insert or parse for this context in the rule, but if I do insert it, then all asset and component requests break. If I just parse it, then the generated outgoing links are "broken" because they lack this context.
(I have older posts which illustrate something similar, but I think this is a pretty easy example to understand).
Thanks!
Levi
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2559849.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 18:21:14 -0300, xfile80303 <le...@grokers.net> escreveu:
> Hi Thiago, all,
Hi!
> Thanks for adding this feature.
:)
> Is there a way to utilize this to only rewrite page render requests and
> not component or asset requests? I know it is pretty early on in the
> request lifespan, but without this discrimination this feature is not
> nearly as useful to me (and possibly others?).
It's really very early in the request handling pipeline. Maybe Tapestry
should add some way (maybe methods in the Request instance) that tells if
the given request is an page one or an event one or an asset one or etc.
Don't forget that every rules can choose if it will overwrite the request
(returning another Request instance) or not, so your rule must first check
if the request is one that needs to be rewritten or not. What exactly is
the URL rewriting you want to do?
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by xfile80303 <le...@grokers.net>.
Hi Thiago, all,
Thanks for adding this feature.
Is there a way to utilize this to only rewrite page render requests and not component or asset requests? I know it is pretty early on in the request lifespan, but without this discrimination this feature is not nearly as useful to me (and possibly others?).
Cheers,
Levi
Em Mon, 30 Mar 2009 15:16:41 -0300, Thiago H. de Paula Figueiredo
<th...@gmail.com> escreveu:
> All feedback is welcome. As 5.1.0.2 is an alpha release, there can be
> non-backward changes to the URL rewriting support. ;)
Oops, forgot to mention that one possible improvement is to add boolean
rewritesInboundURLs() and rewritesOutboundURLs() to URLRewriterRule, so
each rule is only executed for inbound or outbound links.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
--
View this message in context: http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2559716.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
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 15:16:41 -0300, Thiago H. de Paula Figueiredo
<th...@gmail.com> escreveu:
> All feedback is welcome. As 5.1.0.2 is an alpha release, there can be
> non-backward changes to the URL rewriting support. ;)
Oops, forgot to mention that one possible improvement is to add boolean
rewritesInboundURLs() and rewritesOutboundURLs() to URLRewriterRule, so
each rule is only executed for inbound or outbound links.
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: T5.1 URL Rewriting
Posted by "Thiago H. de Paula Figueiredo" <th...@gmail.com>.
Em Mon, 30 Mar 2009 11:49:59 -0300, Blower, Andy
<An...@proquest.co.uk> escreveu:
> I've just been looking at the tests and I can't see any rules that will
> apply only to generated or incoming links. What am I missing? Can anyone
> clue me in?
There's no separation between rewriting inbound or outbound
(Tapestry-generated) links. Both pass through the same URL rewriting rule
chain (pipeline). When generating links, Tapestry builds a mock Request
that is passed to all the rewriting rules. I chose to avoid using two
different chains with different implementations: one for inbound links and
other for another for generated links.
All feedback is welcome. As 5.1.0.2 is an alpha release, there can be
non-backward changes to the URL rewriting support. ;)
The rule4 from the second example in
http://tapestry.formos.com/nightly/tapestry5/guide/url-rewriting.html is a
rule that rewrites generated links. This examples are adapted from the
tests. From that page, last paragraph:
"Note that this applies to rewriting links generated by Tapestry too: a
PageLink to the urlrewritesuccess page with an activation context of login
(path /urlrewritesuccess/login) will generate an a tag pointing to
http://login.domain.com."
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org