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