Howdy, THIS is what request.getContextPath() is for. Don't construct absolute URLs unless you have to -- what's the advantage?
Yoav Shapira Millennium ChemInformatics >-----Original Message----- >From: Mike Curwen [mailto:[EMAIL PROTECTED] >Sent: Thursday, January 08, 2004 4:20 PM >To: 'Tomcat Users List'; 'David Wall' >Subject: RE: Webapp names and paths within JSPs for images > >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] This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
