|
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-2025 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.