Paul Singleton wrote:
On 15/05/2012 15:08, Christopher Schultz wrote:
On 5/15/12 5:00 AM, André Warnier wrote:
Personal opinion :<Base> tags are evil. They create all kinds of
issues when you move the app, or change your server configuration.
There shouldn't be any real reason to use them, if your app is
structured properly. Relative paths should work.
+1
I only just found out in the last few months that URIs within a CSS
are /relative to the URI of the CSS/ which blew my mind and, honestly,
makes total sense.
A JSP developer needs to know how (and when) references are resolved in
at least these cases:
<%@ include file="foo" ...
<%@ include file="/foo" ...
<%@ page errorPage="foo" ...
<%@ page errorPage="/foo" ...
<%@ taglib uri="foo" ...
<%@ taglib uri="/foo" ...
<jsp:forward page="foo" ...
<jsp:forward page="/foo" ...
<jsp:include page="foo" ...
<jsp:include page="/foo" ...
<link href="foo" ...
<link href="/foo" ...
<script src="foo" ...
<script src="/foo" ...
<img src="foo" ...
<img src="/foo" ...
<style type="text/css"> p { background:url(foo) } ...
<style type="text/css"> p { background:url(/foo) } ...
[surely there are more, e.g. within in-page JavaScript?]
What *nix minds think of as an "absolute" path e.g. /foo is just
relative to something other than what foo is relative to.
I'll try to find a small prize for whoever is first to provide links to
clear, definitive documentation of how each case above resolves ;-)
Well, if you are willing to up the prize a little bit (like to "medium" or so), here is my
entry for an empirical set of rules :
The first and most important aspect to consider is *who* has to resolve these
references.
And in your examples above, there are clearly two totally distinct cases :
a) a "<%@ include" kind of tag is processed by the server software, before the page is
sent to the browser. So in this case, the server software has to have a point of
reference on the server, to resolve them.
The browser will never see those tags, as they will have been replaced by generated HTML
before they are sent out.
b) the other cases which you mention are tags which "persist" in the pages sent to the
browser, and thus it is the browser who will have to resolve them.
I will start with those.
When the browser resolves such a reference, its "point of reference" is the current
document, or rather the URL from which this current document was obtained.
(Unless you changed it explicitly using a <base> tag - which is why they are
evil..)
... Oh well, I see that Christopher beat me to it, and I agree 100% with his
notes.
Jeez he types fast..
So I guess I've missed the prize.
I can't see a really good reason to use a<base> tag these days unless
you want fully-qualified paths for all URLs and want to save on
bandwidth or something like that.
We found one, but if you are just using <base> empirically, to make
things work when you don't really understand "relative paths", then it's
probably worth time spent figuring out how to manage without it.
Paul Singleton
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
