-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 André,
On 9/20/2011 4:45 PM, André Warnier wrote: > Christopher Schultz wrote: >> You can't do this unless all your JSPs are at the same directory >> level, say, in "myapp". > > Why not ? Suppose all stylesheets are in > (tomcat_dir)/webapps/myapp/css/, and all images in > (tomcat_dir)/webapps/myapp/images/, then if you have this JSP in > e.g. (tomcat_dir)/webapps/myapp/level2/mypage.jsp, and it refers to > a stylesheet, the link should be "../css/mystyle.css", that's all. > And if you have this JSP in e.g. > (tomcat_dir)/webapps/myapp/level2/level3/mypage.jsp, and it refers > to a stylesheet, the link should be "../../css/mystyle.css", that's > all. (You always know where, *relative to your JSP*, the stylesheet > is.) The URLs are relative to the resource's URI, not the file. So, if you have one file include another file like this: main_page.jsp: <%include src="subdir/subpage.jsp" %> subdir/subpage.jsp: <link rel="stylesheet" href="../css/my.css" /> This presents a problem because the browser is looking at http://host/webapp/main_page.jsp and the CSS reference points to http://host/css/my.css instead of http://host/webapp/css/my.css. > And if any of these stylesheets refers to an image, it should do it > as "../images/image.jpg", because by the time the broser fetches > the stylesheet, the "base href" is the URL whence the stylesheet > came from Correct. That's nice, but only if you can get the stylesheet loaded properly in the first place. It's standard, common, and recommended practice to make all URLs relative to the webapp by using the tools provided by the servlet spec to effectively build all URLs like this: <a href="<%= response.encodeURL(request.getContextPath() + "/my/relative/url")" %> All JSP tags, etc. use the same technique and it's more consistent to use those tools to build all URLs instead of special-casing all .css resources or whatever. This also avoids the problem of multi-directory-level file inclusion. > The doubt comes only in a (contrived) case like the following : > Imagine you have a JSP containing a link to a stylesheet as follows > : <style > src="utilities/servlets/css_servlet?css=somedir/mystyle.css" ..> > (with "css_servlet" being some code which cleverly retrieves the > named css file from somewhere else altogether), then by the time > the browser gets this stylesheet, it thinks its base path is > "http://myhost.cpy.com/myapp/utilities/servlets/css_servlet"; That depends upon the URI of the top-level page, not the exact file that is generating content at a given time. See my example above. All I'm saying is that it's safer to use relative-to-the-context-root URIs than any other strategy to avoid these errors. > The point is, if you use relative paths properly, then you can zip > your entire app, give the zip your designer who will unzip it in > his directory /chris/project1/, and work on it with a local html > design tool. When he/she is done, "it" will zip it again and send > it back to you to unzip wherever you feel like (at > webapps/my_newapp if you like), and all links should still work. If you are using JSP and your designer is expecting to read non-dynamic files directly from the disk (with no JSP interpreter), things are going to go badly. Most non-trivial webapps using JSPs have many includes, forwards, etc. in order to build a single page and it's just more complicated than you are making it sound. Projects like JSF, Apache Tiles, etc. all muddy the waters even more for a "pure" designer and make it next to impossible to use a zip-file-of-the-JSPs as a basis for editing. > It's only if you start playing ganes like above that everything > falls apart. And as soon as you start using absolute links ... > forever rule you it will, the dark side of the force. Remember, the Dark Side kicked some serious ass. Seriously, relative-to-the-context is the way to go. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk558RwACgkQ9CaO5/Lv0PAyjQCeJ2eN3Pd1Dwt8LtI4cm5Vfc2M zo8AnjyA2DaaDQ96FY9nJ6tI+k059Qrj =vB1f -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
