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
eed 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 cont
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
pgrading 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
--
Vi
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-Rewri
e. 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.
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
;> 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, t
> > 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
ason 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 Tape
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
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-
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).
cated 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
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
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 unsubs
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
o 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-uns
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
thiago
-
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 the Tapestry
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-
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
31 matches
Mail list logo
