On Nov 7, 2013, at 1:24 PM, Christopher Schultz <ch...@christopherschultz.net> wrote:
> 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. You keep saying this but you have yet to explain why the practice is so intrinsically bad. > 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. Again, you have yet to give a convincing reason why things "ought" to be that way. Baking in the context-path has the effect of introducing a runtime requirement into the final product. Specifically, it demands that whatever path an application is deployed to in Tomcat be maintained all the way back to the user's browser. Now if there's a good reason for having that requirement, fine. But if not, why add it? > 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.). Yes, somebody has to write that filter, or if they're already building a framework for other reasons they can include that functionality. Either way, it's a small, one-time investment. Application developers don't have to worry about it. They just plug it in and go. As for a filter not catching things, that's a bug and should be detected by testing. If it's not, you've got a management problem, not a technical one. - Milo Hyson Chief Scientist CyberLife Labs, Inc.
