On Thu, 19 Jul 2012 05:18:39 -0300, Lance Java <lance.j...@googlemail.com>
wrote:
In option 1:
- The URL displayed in the user's browser will be different to the
@Injected request's getPath()
That's exactly the point of URL rewriting! :)
- I can only assume that the HTTPServletRequest will not be cloaked so
@Inject HTTPServletRequest and @Inject Request will have conflicting path
values
Yep, but only Tapestry itself only uses Request, not HttpServletRequest,
and so should you.
- If I wanted to calculate the relative location of "/mysite/" based on
Request.getPath(). I would get the calculation wrong in some cases since
the cloaked Request.getPath() is exactly the same for all URLs
(mentioned above)
Why would you need to calculate relative locations? I've been using
Tapestry 5 since 5.0.4 or 5.0.5 and I never needed to do that. Let
Tapestry do that for you.
In option 2:
- The URL displayed in the user's browser is the same as
Request.getPath()
So there's no URL rewriting anymore.
I'm not sure that this URL calculation is a problem but I don't see a
need to cloak the @Inject'ed Request. For this reason, I lean towards
option 2.
Option number 2 has the same problem as LinkTransformer API: you need to
decorate or advise ComponentEventLinkEncoder, specifically the decode*()
methods, so can't use them in your URL rewriting logic for parsing URLs
and you end up doing that yourself.
--
Thiago H. de Paula Figueiredo
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
