× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.