my dog learned polymorphism*
The moose likes JSP and the fly likes A few questions about JSTL Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "A few questions about JSTL" Watch "A few questions about JSTL" New topic
Author

A few questions about JSTL

L Duperval
Ranch Hand

Joined: May 14, 2003
Posts: 63
Hi,
I have a setup that looks like this:
  • I have a set of JSP pages that have forms
  • The submit buttons of the forms send the data and the name of the next page to a servlet (which can be different from one JSP to the next)
  • The servlet receives the data, possibly sticks some values in the session, possibly sticks or modifies the request parameters
  • After processing, the servlet has to hand over control to the next JSP
  • The next JSP will read some of the session parameters, will read some of the request parameters and output HTML accordingly


  • I want to build a sample version of this using three technologies: plain JSP and servlets, JSP+servlets+JSTL and finally, struts. I've managed to get the JSP+servlets part working OK. Now I want to look at JSTL, and in the process I want to eliminate as much Java code in my JSP's as possible.
    The problem I've got now is that handing data from my JSP to my servlet and then going to the next page isn't working. In my servlet I have:

    it works fine for JSP+servlets where I explicitly set my base-ref to <host>/<context>. I can then refer to my next page as /nextpage.jsp
    In the JSTL pages, I removed the <base> tag and I use <c:url>. The resulting url is "/<context>/nextpage.jsp". For some reason, when my servlet tries to forward the request, I get an error saying that /<context>/nextpage.jsp is not available.
    Another question I have is, how do I get session objects when displying the page? At one point, I did have something that worked partially (I was using scriptlets to specify my next page instead of using tags). However, when I tried to get the value of a session object, I did not get what I expected. For example, if you refer to the code above, I tried and what I got was ${anObject_NotAString} in my output. I do have accessors in my object.
    Well, that's enough for now!
    Thanks,
    L


    Live Free, Live Happy
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61224
        
      66

    I get an error saying that /<context>/nextpage.jsp is not available.

    The context path should not be included in forwarding URLs (which are expected to be context-relative).
    if you refer to the code above, I tried ${anObject_NotAString.field}

    Why did you name the attribute "attr" is that's not how you wanted to refer to it? In other words, given the code you showed, the EL reference to the scoped variable would be ${attr}.


    [Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61224
        
      66

    or if you wanted to be more explicit about it: ${sessionScope.attr}
    L Duperval
    Ranch Hand

    Joined: May 14, 2003
    Posts: 63
    Originally posted by Bear Bibeault:

    Why did you name the attribute "attr" is that's not how you wanted to refer to it? In other words, given the code you showed, the EL reference to the scoped variable would be ${attr}.

    That was a typo on my part. You replied while I was trying to fix my error. yes, I am trying to access ${attr.field}.
    As for the URL, I'm not providing a context. The <c:url> tag is. My jsp just says
    <a href="<c:url value"/myurl/mypage.jsp"/>">Next page</a>
    The resulting HTML will look like this:
    <a href="/appcontext/myurl/mypage.jsp">Next page</a>
    According to this article, that is to be expected. What I don't understand is why after going through my servlet, Tomcat (5.0.19) complains that the page isn't available. The error says:

    Maybe the servlet's context is not what I'm expecting? I'll try looking into that to see.
    L
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61224
        
      66

    As I said, the context shouldn't be there, so when you forward to "/appcontext/jstl/overview.jsp", the resource that it's trying to find is "/appcontext/appcontext/jstl/overview.jsp", which of course does not exist.
    Backing up a bit:
    The whole purpose of using JSTL and getting the Java out of the pages (a worthwhile endeavor -- I rarely have any Java code on my pages anymore) is to abstract the pages so that they are easier to read, easier to maintain and less error-prone. So in such an abstracted environment, why would you make one JSP know the URL of another? I would factor out the URL-ness of where the next target should be from the pages and put it in the controllers themselves.
    L Duperval
    Ranch Hand

    Joined: May 14, 2003
    Posts: 63
    Originally posted by Bear Bibeault:
    As I said, the context shouldn't be there, so when you forward to "/appcontext/jstl/overview.jsp", the resource that it's trying to find is "/appcontext/appcontext/jstl/overview.jsp", which of course does not exist.


    Makes sense.


    So in such an abstracted environment, why would you make one JSP know the URL of another? I would factor out the URL-ness of where the next target should be from the pages and put it in the controllers themselves.

    Good question. In my case, I guess my JSP is my view, my servlet is the controller and whatever data store the controller uses is the model. What you're telling me is that my servlet should know what the next page of a given request is, right?
    The reason I wanted to provide the next page is because the same servlet can be called from a French page or from an English page. When the servlet has processed the information, the page in the proper language must be used to display it. The name of the page may not be the same in French and in English.
    Another issue is that at the current stage, I'm not sure that one servlet will be associated with one flow only. Most likely not. I felt that if the servlet didn't know about the flow, but was told where to send data to be displayed, it would solve both these issues. But it looks like it's insufficient.
    I believe Struts has some support for this, but I'm not alone developing this and I would have to be able to convince the rest of the team that it is better than just JSTL (which in itself, is better than using JSP+servlets only).
    L
    Bear Bibeault
    Author and ninkuma
    Marshal

    Joined: Jan 10, 2002
    Posts: 61224
        
      66

    The name of the page may not be the same in French and in English.

    This seems rather odd to me. In a servlet-controller web app, do users even see the page names? And even if they did, who cares? In a web app URLs are opaque identifiers that users should not be concerned with. I've worked on a number of internationalized web apps and in none were the page names ever localized along with the page contents.
    Another question this all raises: do you really need separate pages for the localized versions? Are they that different that you cannot use the facilities of the JSTL fmt tags to handle localization within a shared page?
    But if it is a hard requirement that separate pages with localized names are needed, it speaks even more loudly for abstraction of the page URLs. When you get to your Struts (ugh) version, you will see that it abstracts the page URLs. You could use a simpler such scheme in a non-frameworked version.
    One tactic: (assuming that the app is localized on a per-user basis)
    - each page could be assigned a keyword
    - keyword to URL mappings are stored in a set of localized Maps, one per language, the keywords are common in the English and French Maps (and Spanish and German and so on) with the maps stored in application context
    - Pages are referred to by their keyword rather than URL
    - When it comes time to forward, page keywords are translated to URLs using one of the localized Maps
    - Which localized map is used for translation is governed by a session variable set on a per-user basis
    This would remove knowledge of URLs and differences in page names from your JSPs, (Btw, the whole topic of whether the JSPs should be telling the servlets where to go or otherwise is another architectural ball of wax).
    For example, a hypothetical "help" page could have a keyword like "HelpPage", which in the English localized Map translated to "/WEB-INF/pages/en/help.jsp", while in the French localized Map would translate to "/WEB-INF/pages/fr/aide.jsp".
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: A few questions about JSTL