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:d.wall@(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" <jeffrey.green@(protected)>
> To: "'Tomcat Users List'" <tomcat-user@(protected)>;
> "'David Wall'" <d.wall@(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:d.wall@(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: tomcat-user-unsubscribe@(protected)
> > For additional commands, e-mail: tomcat-user-help@(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: tomcat-user-unsubscribe@(protected)
> For additional commands, e-mail: tomcat-user-help@(protected)
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-user-unsubscribe@(protected)
For additional commands, e-mail: tomcat-user-help@(protected)
