|
Joe, have you tried using <%=request.getContextPath()%> eg <LINK rel="stylesheet" href="<%=request.getContextPath()%>/common/include/std.css" type="text/css"> thats what I use in my jsps, and it gets rid of the WDSC broken link message cheers Colin.W ----- Original Message ----- From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx> To: "'Websphere Development Studio Client for iSeries'" <wdsci-l@xxxxxxxxxxxx> Sent: Saturday, February 07, 2004 9:49 PM Subject: [WDSCI-L] Relative and absolute links > Can someone explain this to me? > > I set up a web project: > > /Test > /Web Content > /myapp > /folder1 > /common > /include > > In folder1, I have a JSP called logon.jsp, in include I have a CSS file > called std.css, the sources of which follow: > > /myapp/folder1/logon.jsp > > <HTML> > <HEAD> > <LINK rel="stylesheet" href="../../common/include/std.css" > type="text/css"> > </HEAD> > <BODY> > <P>Place content here.</P> > </BODY> > </HTML> > > > /commoninclude/std.css > > BODY { color : green; } > > > As coded above, everything works fine and when run on a server, the JSP > comes up with nice green text. Note however that I have to specify > "../.." on the beginning of my CSS. This is in fact the way WDSC > creates the link. If I wanted a non-relative link, I'd have to include > the context (in WDSC< that's the project name): > > <LINK rel="stylesheet" href="/Test2/common/include/std.css" > type="text/css"> > > > I guess I'm okay with this to some degree. It's awkward that there's no > way to specify going back to the top of my context, but I guess that's > the way the cookie crumbles. So, I use the relative path. > > > However, things change when I try to include the same JSP using the > include() method: > > > Includer.java > > import java.io.*; > import javax.servlet.*; > import javax.servlet.http.*; > > public class Includer extends HttpServlet implements Servlet { > > private static final String url1 = "/myapp/folder1/logon.jsp"; > public void doGet(HttpServletRequest req, HttpServletResponse res) > throws ServletException, IOException > { > res.setContentType("text/html"); > PrintWriter out = res.getWriter(); > getServletContext().getRequestDispatcher(url1).include(req, res); > out.close(); > } > > } > > > I invoke the servlet as such: > > http://myserver/Test2/servlet/Includer > > > With this, the JSP works fine with the context specified in the CSS > link. However, with the relative link, the CSS is not found. Instead, > I have modify the link as so: > > <LINK rel="stylesheet" href="../common/include/std.css" type="text/css"> > > Notice, only ONE level of ".." in the URL. I think this is because when > resolving the link, rather than being relative to "/myapp/folder1" as it > would were the JSP being loaded directly, WebSphere instead takes the > link as being from "/servlet". > > > The workaround is to use the single level of indirection as shown above, > but the resulting problem is that it creates a warning error in my JSP > in WDSC, and as I add more JSPs and more style sheets, I get more and > more warning messages. Can anybody see a way around this issue? > > > 1. Can I tell the servlet which context to use when it is resolving > links on a JSP included with the include() method? That way I could > make it work the same way as if it were loading the JSP directly. > > 2. Is there another way to include the JSP that would get around this > issue? > > Joe > > _______________________________________________ > This is the Websphere Development Studio Client for iSeries (WDSCI-L) mailing list > To post a message email: WDSCI-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/wdsci-l > or email: WDSCI-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/wdsci-l. >
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.