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