I've become used to constructing image URL paths (where necessary) as absolute paths. So I'd do something like: http://<%= request.getServerName() + request.getContextPath() %>/images/foo.gif If you wanted to, you could wrap that String construction up into a taglib or even a method declared in your JSP with a <%! tag. As for escaping HTML for display, there are plenty of taglibs that will do this for you, including JSTL (a 'standard' way of doing it).
> -----Original Message----- > From: David Wall [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 08, 2004 3:11 PM > To: 'Tomcat Users List' > Subject: Re: Webapp names and paths within JSPs for images > > > Well, right now we have a hard-coded app name for the paths > (when we can't rely on relative path names) in the image tags > since making all image tag path names dynamic would be a bit > of a pain, plus it would make those images not appear in > tools like Macromedia that need to be able to resolve the > paths locally. > > It seems that we're either doing this "wrong" or the pretense > that webapps can be deployed using any name chosen at > deployment time simply is not true. I would not be surprised > since I find a lot of plumbing type work is still necessary > when using JSPs. Another one is having to encode all output > so it's HTML safe, including data values that appear in INPUT > value="abc" type tags as well as SELECT and TEXTAREA when > 99.99% of the time we want our output to be HTML safe. While > it's a pain coding-wise, there's also no standard way to do > that encoding so we all write our own routines that convert " > to " and the like. It just seems like there's a lot > more marketing to JSPs right now than is delivered > considering how mature Java/JSPs are already. > > David > > > ----- Original Message ----- > From: "Green, Jeffrey" <[EMAIL PROTECTED]> > To: "'Tomcat Users List'" <[EMAIL PROTECTED]>; > "'David Wall'" <[EMAIL PROTECTED]> > Sent: Thursday, January 08, 2004 12:53 PM > Subject: RE: Webapp names and paths within JSPs for images > > > > I'm running into the exact same issue. It seems that you could use > > HttpServletRequest.getContextPath() or parse through > > HttpServletRequest.getRequestURI() to get the root-relative path of > > the > URL. > > Then prepend that with the image name (or do whatever > manipulation is > > necessary). I've found it tougher to actually get a webapp deployed > "using > > any 'name' I'd like". Hod did you get that working? > > > > -----Original Message----- > > From: David Wall [mailto:[EMAIL PROTECTED] > > Sent: Thursday, January 08, 2004 3:43 PM > > To: Tomcat Users List > > Subject: Webapp names and paths within JSPs for images > > > > > > In theory I should be able to take my webapp (starting with > the base > > directory that contains the WEB-INF subdirectory) and > deploy it using > > any "name" I'd like, so I could easily deploy the same webapp with > > URLs like http://mydomain.com/ (using the root context) or > > http://mydomain.com/app1/ or even http://mydomain.com/app2/ etc. > > > > However, JSPs can include files using the "/" root to indicate I'm > > talking about a file at the top of the webapp directory and > that works > > fine. But images need to include URLs that that aren't > processed by > > tomcat (so it doesn't know about the webapp's "base" > directory), so I > > have to use names like "/images/image.gif" or > "/app1/images/image.gif" > > or "/app2/images/image.gif" depending on where the webapp > was actually > > deployed. > > > > While I can use relative paths for such images much of the > time, when > using > > servlets that redirect/forward or whatever, the "current > directory" is > > not always the same, so you can't just use "images/image.gif" or > > "../images/image.gif" to make it work. > > > > How are people coding their JSPs and servlets that return > IMG tags so > > that the images can always be defined without including the webapp > > path name? > > > > Thanks, > > David > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > ---------------------------------------------------------------------- > > ---- > ---- > > This message is intended only for the personal and > confidential use of > > the designated recipient(s) named above. If you are not > the intended > recipient of > > this message you are hereby notified that any review, > dissemination, > > distribution or copying of this message is strictly > prohibited. This > > communication is for information purposes only and should not be > > regarded > as > > an offer to sell or as a solicitation of an offer to buy > any financial > > product, an official confirmation of any transaction, or as an > > official statement of Lehman Brothers. Email transmission > cannot be > > guaranteed to > be > > secure or error-free. Therefore, we do not represent that this > information is > > complete or accurate and it should not be relied upon as such. All > > information is subject to change without notice. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
