[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 be the best
route, as Thiago suggested. You
On Tue, Apr 7, 2009 at 6:27 AM, Blower, Andy andy.blo...@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
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
: 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 into the URL and application,
such that I can use the same pages to render content
On Tue, Mar 31, 2009 at 1:21 AM, Robert Zeigler robe...@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
On Tue, Mar 31, 2009 at 6:26 AM, Blower, Andy
andy.blo...@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
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
, 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
On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship hls...@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
On Tue, Mar 31, 2009 at 11:53 AM, Thiago H. de Paula Figueiredo
thiag...@gmail.com wrote:
On Tue, Mar 31, 2009 at 11:40 AM, Howard Lewis Ship hls...@gmail.com wrote:
Another option would be to combine the URLRewriterRule with an enum to
define when it is in effect (INCOMING, OUTGOING, BOTH).
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
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
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
]
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
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
Em Mon, 30 Mar 2009 11:49:59 -0300, Blower, Andy
andy.blo...@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
Em Mon, 30 Mar 2009 15:16:41 -0300, Thiago H. de Paula Figueiredo
thiag...@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
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
View this message in context:
http://n2.nabble.com/T5.1-URL-Rewriting-tp2557652p2559716.html
Sent from
Em Mon, 30 Mar 2009 18:21:14 -0300, xfile80303 l...@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
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-unsubscr...@tapestry.apache.org
Em Mon, 30 Mar 2009 18:47:39 -0300, xfile80303 l...@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
/T5.1-URL-Rewriting-tp2557652p2560040.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
Em Mon, 30 Mar 2009 19:28:23 -0300, xfile80303 l...@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
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
Em Mon, 30 Mar 2009 19:47:31 -0300, xfile80303 l...@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
(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
Em Mon, 30 Mar 2009 20:12:30 -0300, xfile80303 l...@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
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
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
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.
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
31 matches
Mail list logo
