tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Baked-in context paths
Date Thu, 07 Nov 2013 21:24:39 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Milo,

On 11/7/13, 2:46 PM, Milo Hyson wrote:
> On Nov 7, 2013, at 7:57 AM, Christopher Schultz
> <chris@christopherschultz.net> wrote:
> 
>> The only way to reliably mutate context-paths during proxying is
>> to re-write the headers and content of the pages. It's
>> miserable.
> 
> Perhaps YOUR experiences have been miserable, but clearly that's
> not the case for everyone. The only headers I've ever needed to
> modify are request URL and cookie path, both of which can easily be
> adjusted with HTTPD directives. As for content, due to my use of
> relative linking, I've never needed to tweak it after leaving
> Tomcat.
> 
>> To be clear, I've *only* been recommending context-relative
>> resources.
> 
> You've been recommending server-relative references. The 
> context-path, by definition, gives a location that is relative to
> the server, and therefore anything it prefixes becomes
> server-relative. A context-relative path is one that is relative to
> the context. Please see 
> http://velocity.apache.org/tools/devel/view/LinkTool.html#setRelative().

Fair
> 
enough: host-relative links. But nobody in their right mind uses
"../../../.." to get to the context-path (which, by definition is
relative to the host)... instead they use request.getContextPath() and
then tack-on a context-relative link to the end of it.

>> Note that it's much more convenient to use Velocity Tools'
>> LinkTool, which not only can construct "relative" URLs, but it
>> will properly encode them with the session id when cookies are
>> not in use. Also note that "relative" links will become
>> context-relative links.
> 
> First of all, LinkTool returns server-relative links, not 
> context-relative. Second, not everybody needs to encode session
> IDs into URLs. In fact, some people don't even use sessions. Were
> these issues for me I would of course take a different approach.
> Third, a single VTL variable is pretty damn convenient. As a
> content developer I just put that in my template and as if by magic
> the links work. Granted, the framework developer had to write code
> to initialize that variable, but it was trivial and only had to be
> done once.

I know how LinkTool works (hint:
http://velocity.apache.org/who-we-are.html)

I'm not saying that you can't make "pure" relative links work. I'm
just saying that writing robust software has led me to make certain
decisions about the way things "ought" to be.. and this is one of them.


>> You have been fairly lucky. You must not use #parse() a lot.
> 
> Except for experimentation, no, I don't. Even if I did, I'm not
> sure why that would be a problem. So far as I know, all parse()
> does is temporarily switch the VelocityEngine to a different
> template.

Yes... and render its output. So let's say you have a template for,
say, menus. Here's an example:

<a href="users/index.vm">Users</a>
<a href="admins/index.vm">Admins</a>
<a href="public/index.vm">Public</a>

Now you want to use your menus in all three of the above pages. So,
for example, you have "users/index.vm":

#parse('/menus.vm')
<p>This is the Users' Page.</p>

Then you also have the admin page:

#parse('/menus.vm')
<p>This is the Admins' Page.</p>

... and all your links are boned. Oh, no problem: just add "../" to
the beginning of all the links in the menu.vm page, right?

<a href="../users/index.vm">Users</a>
<a href="../admins/index.vm">Admins</a>
<a href="../public/index.vm">Public</a>

Great, that works. Until you try to include /menus.vm in your page
with address /context/users/special/index.vm

Your solution? Create a VTL variable (hopefully, actually done
somewhere non-VTL-specific) called $relativeContextPath and use that:

<a href="$relativeContextPath/users/index.vm">Users</a>
<a href="$relativeContextPath/admins/index.vm">Admins</a>
<a href="$relativeContextPath/public/index.vm">Public</a>

So, how do you set that value? Do you have a Filter that takes the
current URL and calculates how many "../" you need to put on it to get
back to the context-root, then stick it in the request? That sounds
like more work to me than this:

<a href="$request.contextPath/users/index.vm">Users</a>
<a href="$request.contextPath/admins/index.vm">Admins</a>
<a href="$request.contextPath/public/index.vm">Public</a>

... and no Filter to fix things up for me. It will also work in the
cases where the Filter does not run for some reason (maybe it's not
configured for all URLs, so 404s slip-through, etc.).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.15 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSfAUVAAoJEBzwKT+lPKRYKLAP/iaiRfUCXCNA3Trxi5rgH6mw
trtU9X+V11XcUftqeNcDv6jEUv6WuVttYL9ZDOjDsDZbDeIZi+8zMfEU0fpZeKau
xpI8Xqdl87cf4aBuNV/CzIawUXdAnx3srPEUao8PRvWhhtTbl7QKTM+rSI9yen8A
+ClEs0lUcdqi5Ul1pudFfoi0ln30Rkku1Y2eAQmbueeZX7NDFiTgR9+7bEmebXd9
LIGOEbgnZsd8tKHELvs2LDL6UYlSK34QHQqO4YICTSHN3Bi17tb6wTf1K7qFufL7
z3xK6DBLQvT9ISr63+JghR10ogZDtiaIqhXkPvBxkbvAbjwr8cG3ikkjqxqUAzhB
GEO7pNU01ZuVnj7gD2XFT+N+Nq8VxlXqfNtN9FTm1/2Jfy7KM91ei0WybFr36j9v
oZsZ81s77WU1/RatS6N4zL/MTuI65V8Eq6pbVMkbTG/2O+8l7qinLL2m+SEdH/1s
qqEmWWwDVL9M9AnWAxbsmxKMI5JCaUIrUDqJR2NpT23SP+FcDpbaW6l4RiroQxzH
iQWTPTWS5pPdwSLvTF68mJ+TxICXKDoSBcurwlnxHT+qV6uqQYf8cDhe7dNDjMah
KB9JbAQ/Lk1sGrisOLkzQPZGOotJmZR6NlQLItBI9yEBPniMcmrpl0yckd6Hj6XJ
mw5y56wgWXLdbdyY03Sa
=aB5B
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message