On Tue, Apr 7, 2009 at 6:27 AM, Blower, Andy 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
om: Blower, Andy [mailto:andy.blo...@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 b
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
3 [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 wee
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
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 u
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 e
On Tue, Mar 31, 2009 at 11:53 AM, Thiago H. de Paula Figueiredo
wrote:
> On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship 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 p
On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship 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.
--
Thi
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 wrote:
> Yeah, I definitely think there needs to be at least /some/ disambiguation
> between request and response.
> A num
> > 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
On Tue, Mar 31, 2009 at 6:26 AM, Blower, Andy
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 int
On Tue, Mar 31, 2009 at 1:21 AM, Robert Zeigler 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
s,
Andy.
> -Original Message-
> From: xfile80303 [mailto:l...@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" in
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 redund
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. d
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 "proces
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
Em Mon, 30 Mar 2009 20:12:30 -0300, xfile80303 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 be
Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 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 th
Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 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).
Em Mon, 30 Mar 2009 19:28:23 -0300, xfile80303 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.).
>
> S
Em Mon, 30 Mar 2009 19:28:23 -0300, xfile80303 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 Re
Em Mon, 30 Mar 2009 18:47:39 -0300, xfile80303 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 s
Em Mon, 30 Mar 2009 18:47:39 -0300, xfile80303 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 ser
Em Mon, 30 Mar 2009 18:21:14 -0300, xfile80303 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
Em Mon, 30 Mar 2009 18:21:14 -0300, xfile80303 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
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 possi
Em Mon, 30 Mar 2009 15:16:41 -0300, Thiago H. de Paula Figueiredo
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(
Em Mon, 30 Mar 2009 11:49:59 -0300, Blower, Andy
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-
30 matches
Mail list logo
