You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Patrick Flaherty <pf...@rampageinc.com> on 2011/09/18 18:55:20 UTC

Links in CSS vs JSPs

Hi,

We have just changed the way we deploy our webapp. We previously were  
putting our app into the ROOT folder under webapps , not good I know.
We now package the app as a war file called myapp.war and place it  
into the webapps folder where it explodes into a folder called myapp.  
Everything
works except for one thing. Our app has the option to let the user  
change the look & feel of the web app using predefined skins which we  
store in a
folder called templates inside the myapp folder. Inside the templates  
folder are the folders that represent all the various skins (skin1,  
skin2 etc ..).
These skin folders contain all the jsps, the css file and images that  
represent the content of each skin.

Here’s the problem which is easily remedied but I want to know why.  
Let me explain. All the skins work except image references in the  
style sheet (css)
cannot be found. Yet images referenced in the jsps are found ! The  
references to the images begin with the url /templates/skin1/images/ 
image1.png in both the
css case and the jsp case. Now to fix the problem I change the url in  
the style sheet by adding my app name in front (i.e. /myapp/templates/ 
skin1/images/image1.png)
and this fixes the problem.

I have no problem with changing this and it’s even logical. I’m just  
trying to understand why this only has presented a problem with links  
in the css and not the jsps.
In firebug the reference to images already have my app name prepended  
to the images automatically. (i.e. /myapp/templates/skin1/images/ 
image2.png) YET the jsps’
references only begin the url /templates/skin1/images/image1.png (no  
prepended app name)

I’m just wondering if this make sense to someone with Tomcat  
experience. Is there a hard and fast rule here I’m missing. What’s  
best practice ?

Thanks in advance
Pat
  

Re: Links in CSS vs JSPs

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Konstantin,

On 9/20/2011 9:09 AM, Konstantin Kolinko wrote:
> Read the official CSS spec from W3C on how relative links in css
> files are resolved. In CSS 2.1 it is in ch.4.3.4. Citing: "For CSS
> style sheets, the base URI is that of the style sheet, not that of
> the source document."

Hmm... I didn't know that. I need to tell our CSS designer, because
her solution has always been to duplicate CSS files and images all
over the place, against my persistent complaints.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk54tQYACgkQ9CaO5/Lv0PCPzgCgkmP+IzM8QrkHVlUDzrdd0PV/
cTIAn0DQCJtN2tnWeCIaJNAwHPWnbzBt
=Kk/o
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by Patrick Flaherty <pf...@rampageinc.com>.
On Sep 20, 2011, at 9:09 AM, Konstantin Kolinko wrote:

> 2011/9/18 Patrick Flaherty <pf...@rampageinc.com>
>>
>> Hi,
>>
>> We have just changed the way we deploy our webapp. We previously  
>> were putting our app into the ROOT folder under webapps , not good  
>> I know.
>> We now package the app as a war file called myapp.war and place it  
>> into the webapps folder where it explodes into a folder called  
>> myapp. Everything
>> works except for one thing. Our app has the option to let the user  
>> change the look & feel of the web app using predefined skins which  
>> we store in a
>> folder called templates inside the myapp folder. Inside the  
>> templates folder are the folders that represent all the various  
>> skins (skin1, skin2 etc ..).
>> These skin folders contain all the jsps, the css file and images  
>> that represent the content of each skin.
>>
>> Here’s the problem which is easily remedied but I want to know why.  
>> Let me explain. All the skins work except image references in the  
>> style sheet (css)
>> cannot be found. Yet images referenced in the jsps are found ! The  
>> references to the images begin with the url /templates/skin1/images/ 
>> image1.png in both the
>> css case and the jsp case. Now to fix the problem I change the url  
>> in the style sheet by adding my app name in front (i.e. /myapp/ 
>> templates/skin1/images/image1.png)
>> and this fixes the problem.
>>
>> I have no problem with changing this and it’s even logical. I’m  
>> just trying to understand why this only has presented a problem  
>> with links in the css and not the jsps.
>> In firebug the reference to images already have my app name  
>> prepended to the images automatically. (i.e. /myapp/templates/skin1/ 
>> images/image2.png) YET the jsps’
>> references only begin the url /templates/skin1/images/image1.png  
>> (no prepended app name)
>
> 1. Isn't it "templates/skin1/images/image1.png" in JSPs?
> (Without leading "/", thus relative to the current page and not to the
> root of the web server).

No, it's actually "templates/$(skin)/images/image1.png" in the JSPs.
>
> How do you print those links in JSPs? (Hard-coded, or you are using
> some tag or API calls?)
Tags
>
> 2. How do you write the URLs in your css files?

Hard coded.
/templates/skin1/images/image1.png    If I try removing the / prefix  
then the path in the browser becomes /appname/templates/skin1/css/ 
templates/skin1/images/image1.png

>
> Read the official CSS spec from W3C on how relative links in css files
> are resolved. In CSS 2.1 it is in ch.4.3.4. Citing:
> "For CSS style sheets, the base URI is that
> of the style sheet, not that of the source document."

Interesting, I can try a relative path starting from the location of  
CSS ?
I read up.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/9/18 Patrick Flaherty <pf...@rampageinc.com>
>
> Hi,
>
> We have just changed the way we deploy our webapp. We previously were putting our app into the ROOT folder under webapps , not good I know.
> We now package the app as a war file called myapp.war and place it into the webapps folder where it explodes into a folder called myapp. Everything
> works except for one thing. Our app has the option to let the user change the look & feel of the web app using predefined skins which we store in a
> folder called templates inside the myapp folder. Inside the templates folder are the folders that represent all the various skins (skin1, skin2 etc ..).
> These skin folders contain all the jsps, the css file and images that represent the content of each skin.
>
> Here’s the problem which is easily remedied but I want to know why. Let me explain. All the skins work except image references in the style sheet (css)
> cannot be found. Yet images referenced in the jsps are found ! The references to the images begin with the url /templates/skin1/images/image1.png in both the
> css case and the jsp case. Now to fix the problem I change the url in the style sheet by adding my app name in front (i.e. /myapp/templates/skin1/images/image1.png)
> and this fixes the problem.
>
> I have no problem with changing this and it’s even logical. I’m just trying to understand why this only has presented a problem with links in the css and not the jsps.
> In firebug the reference to images already have my app name prepended to the images automatically. (i.e. /myapp/templates/skin1/images/image2.png) YET the jsps’
> references only begin the url /templates/skin1/images/image1.png (no prepended app name)

1. Isn't it "templates/skin1/images/image1.png" in JSPs?
(Without leading "/", thus relative to the current page and not to the
root of the web server).

How do you print those links in JSPs? (Hard-coded, or you are using
some tag or API calls?)

2. How do you write the URLs in your css files?

Read the official CSS spec from W3C on how relative links in css files
are resolved. In CSS 2.1 it is in ch.4.3.4. Citing:
"For CSS style sheets, the base URI is that
of the style sheet, not that of the source document."

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by André Warnier <aw...@ice-sa.com>.
Patrick Flaherty wrote:
> 
...

> 
> My question was about why JSP links work *without* the app prefix and 
> the CSS links do not. I think Chris' answer of the JSPs are dynamic
> and intern automatically get the app prefix where CSS are not dynamic 
> and therefore the CSS link has to account for the app prefix.
> 
> How it is fixed André was not the issue, but why JSP links and CSS links 
> behave differently.
> 

I understand. But what I am saying is that I see no reason why the CSS links should have 
to account for the app prefix.
It seems to me that if the CSS links (or rather, the links to images /within/ the CSS 
files) are expressed properly, then they should not have to account for the app prefix.
And that if this is true, it saves a lot of aggravation at various levels.

Or else I am missing something.


Example :

a) a JSP file is located at (tomcat_dir)/webbaps/myapp/some_file.jsp
and the browser calls this as "http://myhost.cpy.com/myapp/some_file.jsp"

b) this JSP file contains a reference to a stylesheet, which is stored at
(tomcat-dir)/webapps/myapp/css/style1.css.
The reference in the JSP page is
<style src="css/style1.css" ..>
Since this reference is inside the page which was retrieved as 
"http://myhost.cpy.com/myapp/some_file.jsp", the browser interprets this reference as 
meaning that it should fetch the resource located at
"http://myhost.cpy.com/myapp/css/style1.css"
and it does fetch it, succesfully.

c) in this stylesheet, there is a reference to an image, stored at 
(tomcat_dir)/webapps/myapp/images/image1.jpg.
In the stylesheet, the reference to that image has a URL of
"../images/image1.jpg".
The browser, when comes the time to fetch this image, will interpret this as
"http://myhost.cpy.com/myapp/images/image1.jpg"
and fetch it succesfully.

Or not ?

By playing with various techniques as explained by Chris previously, you can in the end 
get the same result.
But what I am saying is that, if the usage is similar to what I am using in the above 
example, applying these techniques should not be /necessary/, if the links themselves are 
correctly expressed in the JSP and stylesheet documents.

In my experience, such "dynamic techniques" (or hardcoded absolute links) are necessary
sometimes, when some documents are returned (dynamically) by a JSP page or a servlet (in 
other words, code), because then the browser does not know what the real "base href" is, 
and it can thus get confused.  But not in a case like above, where basically we are 
talking about static documents, retrieved directly by the browser.




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by Patrick Flaherty <pf...@rampageinc.com>.
On Sep 19, 2011, at 6:06 PM, André Warnier wrote:

> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> Patrick,
>> On 9/18/2011 12:55 PM, Patrick Flaherty wrote:
>>> All the skins work except image references in the style sheet (css)
>>> cannot be found. Yet images referenced in the jsps are found!
>> Your JSPs are dynamic and include the webapp prefix, since you
>> (evidently) properly prefixed and encoded your URLs (good for you).
>> Your CSS files are not dynamic and, unless you put the prefixes on
>> there, your images will not be found. Note that any included CSS  
>> files
>> will also not be found (i.e. CSS includes CSS) for the same reason.
>>> Is there a hard and fast rule here I’m missing. What’s best
>>> practice ?
>> I dunno about best practice, but we do what you are doing: put the
>> webapp prefix into the CSS files and don't forget to change it if you
>> re-locate the webapp to another prefix (which pretty much never  
>> happens).
>> There are other options that I can think of off the top of my head:
>> 1. Use the HTML <base /> tag to set the base URL in your dynamic  
>> pages.
>>   Any relative URLs will be relative to that base. This may ruin
>>   the URLs that you have carefully and properly prefixed and escaped
>>   in your JSPs, but it's an option.
>> 2. Make your CSS files dynamic: have Tomcat serve them and perform  
>> the
>>   context-path translation on the fly.
>> 3. Use server-side content filtering for .css files. This is roughly
>>   the same as #2 except that you would use a simpler string-replace
>>   mechanism instead of a fully-dynamic content-generation technology
>>   (such as JSP, etc.).
>> 4. Write a bunch of URL rewrite rules that match the CSS/image files
>>   that you know aren't in the "right" place. This is going to be
>>   a pain in the neck.
>
> And any of the above will cause problems if you want to give your  
> app to a graphic designer, who will move these pages to his  
> workstation and try to work on them.
>
>> I'm sure there are other options.
>
> What I do not understand here (maybe due to my lack of knowledge of  
> JSP pages logic) is why one would need to "fix" anything, if the  
> links are correctly spelled-out in the first place, taking into  
> account how a browser handles absolute/relative links.
>
> e.g. imagine this structure :
>
> (catalina_base)/webapps/
>                       myapp/ (contains *.JSP pages)
>                            /images/ (contains images)
>                            /css/ (contains stylesheets)
>
> If the JSP pages contain links to stylesheets located in "myapp/ 
> css", their reference should say : href(or src)="css/name-of- 
> stylesheet.css"
> If the css files in turn contain links to images, they can be  
> expressed as : src="../images/some-image.jpg"
> And so on.
> If you then move "en block" the whole "myapp" somewhere else, all  
> links should keep working just fine.
>
> Or does something there not work in a webapp/JSP context ?

My question was about why JSP links work *without* the app prefix and  
the CSS links do not. I think Chris' answer of the JSPs are dynamic
and intern automatically get the app prefix where CSS are not dynamic  
and therefore the CSS link has to account for the app prefix.

How it is fixed André was not the issue, but why JSP links and CSS  
links behave differently.

I will go with that explanation and appreciate your thoughts on this.


>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>


Re: Links in CSS vs JSPs

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> André,
> 
> On 9/19/2011 6:06 PM, André Warnier wrote:
>> What I do not understand here (maybe due to my lack of knowledge of
>> JSP pages logic) is why one would need to "fix" anything, if the
>> links are correctly spelled-out in the first place, taking into
>> account how a browser handles absolute/relative links.
>>
>> e.g. imagine this structure :
>>
>> (catalina_base)/webapps/ myapp/ (contains *.JSP pages) /images/
>> (contains images) /css/ (contains stylesheets)
>>
>> If the JSP pages contain links to stylesheets located in
>> "myapp/css", their reference should say : href(or
>> src)="css/name-of-stylesheet.css"
> 
> 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.)

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, thus always
"http://myhost.cpy.com/myapp/css/mystyle.css".
To fetch the image, the browser will
- strip the last element of the stylesheet path (mystyle.css), leaving
"http://myhost.cpy.com/myapp/css/"
- add the image URL ("../images/image.jpg"), thus ending up
"http://myhost.cpy.com/myapp/css/../images/image.jpg", which is a valid and correct URL.

You can redo this with the /myapp/level2/level3 JSP and stylesheet if you want, it does 
not make a difference.



> 
>> If the css files in turn contain links to images, they can be
>> expressed as : src="../images/some-image.jpg" And so on.
> 
> This doesn't work if there are JSPs included in others from various
> levels in the directory tree. It works great when the world is flat...
> after that, everything goes to hell.

But it does work.  If you have JSP's that include others, that gets resolved at the server 
level, no ?  By the time the browser gets this one *html* page, it is coming from one 
definite URL (the URL from which the browser requested it), so the browser has no doubt.

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", and /then/, 
if this css file contains a reference to an image (like "../images/image.jpg"), the 
browser will be confused, because it will "build" the URL to this image as
"http://myhost.cpy.com/myapp/utilities/images/image.jpg"
and thus get it wrong (probably).

So don't do that.

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.

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

André,

On 9/19/2011 6:06 PM, André Warnier wrote:
> What I do not understand here (maybe due to my lack of knowledge of
> JSP pages logic) is why one would need to "fix" anything, if the
> links are correctly spelled-out in the first place, taking into
> account how a browser handles absolute/relative links.
> 
> e.g. imagine this structure :
> 
> (catalina_base)/webapps/ myapp/ (contains *.JSP pages) /images/
> (contains images) /css/ (contains stylesheets)
> 
> If the JSP pages contain links to stylesheets located in
> "myapp/css", their reference should say : href(or
> src)="css/name-of-stylesheet.css"

You can't do this unless all your JSPs are at the same directory
level, say, in "myapp".

> If the css files in turn contain links to images, they can be
> expressed as : src="../images/some-image.jpg" And so on.

This doesn't work if there are JSPs included in others from various
levels in the directory tree. It works great when the world is flat...
after that, everything goes to hell.

> If you then move "en block" the whole "myapp" somewhere else, all
> links should keep working just fine.
> 
> Or does something there not work in a webapp/JSP context ?

That will work in a JSP context... it's just that the recommended
technique is to use "relative-absolute" (a term I just made-up: a URI
starting with a '/') URI to reference everything. With dynamic
includes, etc. it's very easy to get relative links all confused and
nothing works.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk54tFMACgkQ9CaO5/Lv0PBTdQCeIpr6LNVplO0Nbw07rRevjqud
J2wAoL/zIoICL7fx0vinP6AksKFCVBYg
=VcjM
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Patrick,
> 
> On 9/18/2011 12:55 PM, Patrick Flaherty wrote:
>> All the skins work except image references in the style sheet (css)
>>  cannot be found. Yet images referenced in the jsps are found!
> 
> Your JSPs are dynamic and include the webapp prefix, since you
> (evidently) properly prefixed and encoded your URLs (good for you).
> Your CSS files are not dynamic and, unless you put the prefixes on
> there, your images will not be found. Note that any included CSS files
> will also not be found (i.e. CSS includes CSS) for the same reason.
> 
>> Is there a hard and fast rule here I’m missing. What’s best
>> practice ?
> 
> I dunno about best practice, but we do what you are doing: put the
> webapp prefix into the CSS files and don't forget to change it if you
> re-locate the webapp to another prefix (which pretty much never happens).
> 
> There are other options that I can think of off the top of my head:
> 
> 1. Use the HTML <base /> tag to set the base URL in your dynamic pages.
>    Any relative URLs will be relative to that base. This may ruin
>    the URLs that you have carefully and properly prefixed and escaped
>    in your JSPs, but it's an option.
> 
> 2. Make your CSS files dynamic: have Tomcat serve them and perform the
>    context-path translation on the fly.
> 
> 3. Use server-side content filtering for .css files. This is roughly
>    the same as #2 except that you would use a simpler string-replace
>    mechanism instead of a fully-dynamic content-generation technology
>    (such as JSP, etc.).
> 
> 4. Write a bunch of URL rewrite rules that match the CSS/image files
>    that you know aren't in the "right" place. This is going to be
>    a pain in the neck.
> 

And any of the above will cause problems if you want to give your app to a graphic 
designer, who will move these pages to his workstation and try to work on them.

> I'm sure there are other options.
> 

What I do not understand here (maybe due to my lack of knowledge of JSP pages logic) is 
why one would need to "fix" anything, if the links are correctly spelled-out in the first 
place, taking into account how a browser handles absolute/relative links.

e.g. imagine this structure :

(catalina_base)/webapps/
                        myapp/ (contains *.JSP pages)
                             /images/ (contains images)
                             /css/ (contains stylesheets)

If the JSP pages contain links to stylesheets located in "myapp/css", their reference 
should say : href(or src)="css/name-of-stylesheet.css"
If the css files in turn contain links to images, they can be expressed as : 
src="../images/some-image.jpg"
And so on.
If you then move "en block" the whole "myapp" somewhere else, all links should keep 
working just fine.

Or does something there not work in a webapp/JSP context ?



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Patrick,

On 9/18/2011 12:55 PM, Patrick Flaherty wrote:
> All the skins work except image references in the style sheet (css)
>  cannot be found. Yet images referenced in the jsps are found!

Your JSPs are dynamic and include the webapp prefix, since you
(evidently) properly prefixed and encoded your URLs (good for you).
Your CSS files are not dynamic and, unless you put the prefixes on
there, your images will not be found. Note that any included CSS files
will also not be found (i.e. CSS includes CSS) for the same reason.

> Is there a hard and fast rule here I’m missing. What’s best
> practice ?

I dunno about best practice, but we do what you are doing: put the
webapp prefix into the CSS files and don't forget to change it if you
re-locate the webapp to another prefix (which pretty much never happens).

There are other options that I can think of off the top of my head:

1. Use the HTML <base /> tag to set the base URL in your dynamic pages.
   Any relative URLs will be relative to that base. This may ruin
   the URLs that you have carefully and properly prefixed and escaped
   in your JSPs, but it's an option.

2. Make your CSS files dynamic: have Tomcat serve them and perform the
   context-path translation on the fly.

3. Use server-side content filtering for .css files. This is roughly
   the same as #2 except that you would use a simpler string-replace
   mechanism instead of a fully-dynamic content-generation technology
   (such as JSP, etc.).

4. Write a bunch of URL rewrite rules that match the CSS/image files
   that you know aren't in the "right" place. This is going to be
   a pain in the neck.

I'm sure there are other options.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk53oi4ACgkQ9CaO5/Lv0PDnGwCeKJOSDGA6m8Zn5t/rXMqCYoxV
odQAoL/fL3+MahdfAoS70JDGEvOe6+vg
=TcFo
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Links in CSS vs JSPs

Posted by André Warnier <aw...@ice-sa.com>.
Hi.

I believe that the problem you are having has nothing to do with Tomcat per se, and 
everything to do with how absolute and relative link references work in the WWW (or in 
HTTP/HTML) in general.

You need a tutorial on that subject, and to always consider what happens *from the 
browser's point of view* when it sees a link to a resource, in a page which it just loaded 
from a server.

Here is a summary introduction :

a) the browser retrieves a page from the URL 
"http://somehost.cpy.com/some/path/document.html".
That is now the "current page".

b) in this document, there is a link to another resource to be loaded on-the-fly, like an 
<img> tag, or a <style> or a <script> tag, and in this link is a URL, from which this 
resource can be retrieved.
The browser will attempt to retrieve this resource (image, stylesheet, javascript,) using 
this URL.

c) if the link URL is not "complete" (meaning : consisting of the whole combination of 
protocol, host, and path, like "http://somehost.cpy.com/some/path/basic.css"), then the 
browser follows some strict rules to "complete" this URL.

For example, if the link's URL was a *relative* URL like "styles/basic.css", then the 
browser starts from the URL of the current page (in this case 
"http://somehost.cpy.com/some/path/document.html"), removes the last component 
(document.html), and appends the *relative* URL to that, giving in this case :
"http://somehost.cpy.com/some/path/styles/basic.css".
Then it tries to retrieve the resource at that address.

If the link's URL is *absolute*, like "/styles/basic.css" (the starting "/" makes all the 
difference), then the browser starts from the URL of the current page (in this case 
"http://somehost.cpy.com/some/path/document.html"), removes the entire path part 
(/some/path/document.html), and appends the link URL to that, giving in this case :
"http://somehost.cpy.com/styles/basic.css".
Then it tries to retrieve the resource at that address.

The above logic is recursive, in the sense that if your browser retrieves a page and finds 
links in it, it will apply the above logic to retrieve these other elements.
Then within the elements retrieved, if there are further links to other things, it will 
again apply this logic to retrieve them. The "base" for each link evaluation is always the 
URL under which it retrieve the container of the link.

So now you have some mental gymnastic to do : retrieve your top page in your browser, look 
at its source, figure out how the browser (according to the above logic) fetches the 
embedded resources (like the stylesheet); then recursively, from the stylesheet, how it 
interprets the links in the stylesheet to retrieve the images.
(Using a browser plugin like HttpFox (for Firefox) or Fiddler2 (for IE) also helps.)
Then fix your pages and other resources, so that they present the links to the browser 
correctly.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org