How do you handle rendering relative URLs so that:
1. Your application is independent of the application context it's deployed to
2. You don't end up with lots of ugly code in your views
3. The solution will work on any J2EE server
I have several approaches, but I can't find any "best practices" discussions on this subject so I thought I'd start one.
Use JSTL tag library (http://java.sun.com/j2ee/1.4/docs/tutorial/doc/JSTL4.html#wp64122)
Example:
<%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"%>
<a href="<c:url value="/index.html"/>"> Home </a>
> I think I'd add a Filter which passes on a
> HttpServletResponseWrapper prepending the context
> path to any site-relative URL (starting with "/") in
> its encodeURL() method. Never had to do this, though.
Hmm... why not? Do you not do web stuff, or do you not build apps to be portable between application contexts?
> <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core"%>
> <a href="<c:url value="/index.html"/>"> Home</a>
My main problem with that is that it's ugly as sin.
I should add that the approaches I usually use are:
1. Scriptlets.
<a href="<%= request.getContextPath() %>/foo">...</a>
Suffers from the "ugly as sin" issue.
2. Insert a scripting variable in the controller.
<a href="${ctx}/foo">...</a>
Prettier, but feels a bit fragile.
3. JSTL or custom tags.
Discussed above. Very ugly.
4. Put a <base ..> element in the header.
This last one works pretty well - but it doesn't seem to be common current practice which makes me nervous.
Incidentally, my spies tell me that the IIS way of doing things is something like this:
<a href="~/foo" runat="server">...</a>
That seems pretty civilized. It seems odd that this sort of issue isn't addressed somewhere more formally (or maybe it is and I just haven't read it).
> Hmm... why not? Do you not do web stuff, or do you
> not build apps to be portable between application contexts?
Fortunately or unfortunately, they don't have to be portable. The last time I suggested to use WAR files for deployment (instead of just extracting a ZIP), the estimated efforts to make this work where considered too high by the project team, especially as we are in the fortunate (and seducing) position to be able to control the servlet context itself. Additionally, we use custom tag libraries that already incorporate controller and mapping mechanisms and create special URLs. And last but not least, the application context path itself would annoy our (indoor) customers ...
> Can be made prettier. I'm not sure about the JSTL
> tag, but it's easy to create something like
> > <a:link href="/foo">Home</a:link>
>
Yeah, but then you have to do a custom tag for everything that knows about hrefs (e.g. IMG tags) and you have to do something really ugly to cater for additional attributes in the tag (e.g. class, onSubmit etc.) and you still have the problem of any URLs that are included in JavaScript on the page.
> Yeah, but then you have to do a custom tag for
> everything that knows about hrefs (e.g. IMG tags) and
> you have to do something really ugly to cater for
> additional attributes in the tag (e.g. class,
> onSubmit etc.) and you still have the problem
> of any URLs that are included in JavaScript on the
> page.
Yes, that's true. Here's another proposal: create a Filter that passes on a custom OutputStream/Writer pair parsing the contents written and replacing all URLs found in the HTML source. A hell of a job, probably risky and not something I'd call fast ... yet transparent and mighty, once it works.
> Yes, that's true. Here's another proposal: create a
> [url rewriting]
Nah, that's always fragile. Too easy to rewrite something that's intended as content or vice versa.
I'm really looking for ways that people actually currently address this problem rather than "possible approaches."
