Dealing with application names in a JEE web app

Discussion in 'Java' started by markspace, May 23, 2011.

  1. markspace

    markspace Guest

    Hi all,

    I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
    found something that looks like a questionable design issue by the JEE
    folks at Sun (now Oracle, of course) and I'd like to pick your brains
    about how you might deal with it.

    Basically, when developing a JEE web app, the application name gets
    inserted into every URL and associated path. If my app is named
    TechDarwinia, for example, then all URLS look like this:

    http://localhost:8080/TechDarwinia/
    http://localhost:8080/TechDarwinia/faces/readPost.xhtml
    http://localhost:8080/TechDarwinia/rsrc/css/style.css

    The problem is of course that the web app could be renamed anything by
    the deployer/sysop, and I've got strings hard coded to that app name
    TechDarwinia.

    So how do folks write their apps so that they can handle being deployed
    under different names?

    I can think of a couple of solutions, but they don't seem good.

    One solution might be to make the app name an application parameter.
    This would mean that everywhere I have to insert some sort of EL
    variable, or equivalent, and the app takes extra time replacing the
    parameter constantly. Also, the installer has one extra parameter to
    configure, and I'd like to avoid that.

    The app parameter method fails where URLs are required but it's not
    possible to invoke Java. For example, in a static resource like CSS:

    body {
    background:url(/TechDarwinia/rsrc/img/bbg.jpg) left top repeat;
    ....


    Another solution might be, and I haven't investigated this fully, to use
    another agent, like Apache, that has the ability to rewrite URLs before
    they are presented to the container, inserting the app name wherever it
    is lacking. This also requires extra CPU overhead for each request,
    (but only one string swap per request, where the app parameter method
    may require many EL substitutions), and also extra work by an installer.
    This could be very complicated though, as using more than one app at a
    time might make the re-write rules overly complicated.

    Both cases run the risk of two application names colliding, as there's
    no real convention regarding name we apps.


    So, has anyone also encountered issues like this? And how did you fix them?

    Thanks all!
     
    markspace, May 23, 2011
    #1
    1. Advertising

  2. markspace

    Lew Guest

    On 05/23/2011 03:11 PM, markspace wrote:
    > Hi all,
    >
    > I'm delving more heavily into JSP/Servlets and JSF at the moment. I've found
    > something that looks like a questionable design issue by the JEE folks at Sun
    > (now Oracle, of course) and I'd like to pick your brains about how you might
    > deal with it.
    >
    > Basically, when developing a JEE web app, the application name gets inserted
    > into every URL and associated path. If my app is named TechDarwinia, for
    > example, then all URLS look like this:
    >
    > http://localhost:8080/TechDarwinia/
    > http://localhost:8080/TechDarwinia/faces/readPost.xhtml
    > http://localhost:8080/TechDarwinia/rsrc/css/style.css
    >
    > The problem is of course that the web app could be renamed anything by the
    > deployer/sysop, and I've got strings hard coded to that app name TechDarwinia.
    >
    > So how do folks write their apps so that they can handle being deployed under
    > different names?


    Relative URLS.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 23, 2011
    #2
    1. Advertising

  3. markspace

    markspace Guest

    On 5/23/2011 12:30 PM, Lew wrote:

    > Relative URLS.



    That seems worse. Now my pages are all dependent on their location in
    the directory hierarchy. I like to move things around, especially as I
    first start development.

    I guess I could constantly refactor as I move things, but I'd like to
    avoid that also.
     
    markspace, May 23, 2011
    #3
  4. markspace

    markspace Guest

    On 5/23/2011 12:30 PM, Lew wrote:
    > On 05/23/2011 03:11 PM, markspace wrote:
    >> So how do folks write their apps so that they can handle being
    >> deployed under
    >> different names?


    > Relative URLS.



    I found a use-case where this doesn't work.

    Templates are used by various other pages in the web app. They have a
    static location, but their links are processed as if the template's
    "location" in the directory hierarchy was the location of the template
    client.

    Example: I have a template at /rsrc/priv/lnf-template.xhtml which
    includes other resources. Abbreviated example:

    <LNF-TEMPLATE.XHTML>

    <?xml version='1.0' encoding='UTF-8' ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:ui="http://java.sun.com/jsf/facelets"
    xmlns:h="http://java.sun.com/jsf/html">

    <h:head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    <link href="../css/style.css" rel="stylesheet" type="text/css" />
    <title>
    <ui:insert name="title">
    Facelets Template
    </ui:insert>
    </title>
    </h:head>

    <h:body>
    ...
    </LNF-TEMPLATE.XHTML>

    That link href to the style sheet is processed by the client, but the
    client could be any page in the directory hierarchy.

    For example for a client from the root directory (/readPost.xhtml), that
    relative link in the template doesn't work.

    <READPOST.XHTML>

    <?xml version='1.0' encoding='UTF-8' ?>
    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml"
    xmlns:h="http://java.sun.com/jsf/html"
    xmlns:ui="http://java.sun.com/jsf/facelets">

    <h:body>
    <ui:composition template="/rsrc/priv/lnf-template.xhtml" >
    Hello from Facelets
    </ui:composition>
    </h:body>

    </html>

    </READPOST.XHTML>


    Pretty ugly, if you ask me.
     
    markspace, May 23, 2011
    #4
  5. markspace

    Lew Guest

    You left out too much context.

    markspace wrote:
    > Lew wrote:
    >> markspace wrote:
    >>> So how do folks write their apps so that they can handle being
    >>> deployed under different names?


    >> Relative URLS.


    > I found a use-case [sic] where this doesn't work.


    No, you didn't. I meant relative to the app context, not with stupid "../"
    prefixes.

    > Templates are used by various other pages in the web app. They have a static
    > location, but their links are processed as if the template's "location" in the
    > directory hierarchy was the location of the template client.
    >
    > Example: I have a template at /rsrc/priv/lnf-template.xhtml which includes
    > other resources. Abbreviated example:
    >
    > <LNF-TEMPLATE.XHTML>
    >
    > <?xml version='1.0' encoding='UTF-8' ?>
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    > <html xmlns="http://www.w3.org/1999/xhtml"
    > xmlns:ui="http://java.sun.com/jsf/facelets"
    > xmlns:h="http://java.sun.com/jsf/html">
    >
    > <h:head>
    > <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
    > <link href="../css/style.css" rel="stylesheet" type="text/css" />


    What? No!

    <link href="/css/style.css" rel="stylesheet" type="text/css" />

    Here's a line from one of my own personal facelet projects:
    <ui:composition template="/WEB-INF/templates/template.xhtml">

    Here are a couple of lines from that template file:

    ....
    <h:eek:utputStylesheet name="/css/purrtones.css" />
    </h:head>
    <h:body>
    <t:div>
    <ui:insert name="header">
    <h:graphicImage id="logo" value="/images/Duncan_and_the_purrtones.png"
    alt="#{bundle.bandname} logo" styleClass="logo"
    />
    </ui:insert>
    ....

    All those paths are relative to the deployed application name, which is
    "/purrtones" by default, but as you say can change. Thus, the image URL
    becomes, e.g.,
    http://localhost:8080/purrtones/images/Duncan_and_the_purrtones.png
    ..

    > <title>
    > <ui:insert name="title">
    > Facelets Template
    > </ui:insert>
    > </title>
    > </h:head>
    >
    > <h:body>
    > ...
    > </LNF-TEMPLATE.XHTML>
    >
    > That link href to the style sheet is processed by the client, but the client
    > could be any page in the directory hierarchy.
    >
    > For example for a client from the root directory (/readPost.xhtml), that
    > relative link in the template doesn't work.
    >
    > <READPOST.XHTML>
    >
    > <?xml version='1.0' encoding='UTF-8' ?>
    > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    > <html xmlns="http://www.w3.org/1999/xhtml"
    > xmlns:h="http://java.sun.com/jsf/html"
    > xmlns:ui="http://java.sun.com/jsf/facelets">
    >
    > <h:body>
    > <ui:composition template="/rsrc/priv/lnf-template.xhtml" >


    That would translate to "<application-context>/rsrc/priv/lnf-template.xhtml",
    and I am having a hard time correlating that to the CSS example above.

    > Hello from Facelets
    > </ui:composition>
    > </h:body>
    >
    > </html>
    >
    > </READPOST.XHTML>
    >
    >
    > Pretty ugly, if you ask me.


    I use relative links in templates all the time. But you have to start them
    from "/", which translates to the application context root, which is the thing
    you're trying not to repeat.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 23, 2011
    #5
  6. On 11-05-23 04:11 PM, markspace wrote:
    > Hi all,
    >
    > I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
    > found something that looks like a questionable design issue by the JEE
    > folks at Sun (now Oracle, of course) and I'd like to pick your brains
    > about how you might deal with it.
    >
    > Basically, when developing a JEE web app, the application name gets
    > inserted into every URL and associated path. If my app is named
    > TechDarwinia, for example, then all URLS look like this:
    >
    > http://localhost:8080/TechDarwinia/
    > http://localhost:8080/TechDarwinia/faces/readPost.xhtml
    > http://localhost:8080/TechDarwinia/rsrc/css/style.css
    >
    > The problem is of course that the web app could be renamed anything by
    > the deployer/sysop, and I've got strings hard coded to that app name
    > TechDarwinia.
    >
    > So how do folks write their apps so that they can handle being deployed
    > under different names?

    [ SNIP ]

    That "application name" is simply the web context root. A J2EE/Java EE
    application server can host more than one web application, and that
    context root in the request URLs is how the app server knows how to pass
    the request to Web App A and not Web App B.

    You (anyone in the ops chain) have complete control over what the web
    context root is, in the application.xml.

    With respect to your complaint about relative URLs, in response to Lew's
    suggestion to that effect, I don't think *any* system handles arbitrary
    movement of web resources (HTML, JSP, XHTML etc). Regardless of how a
    controller parses the resource path described by the URL (URL parts
    corresponding to directories in a filesystem hierarchy, or something
    different like grabbing resources out of a DB) there still has to be a
    definite mapping. This isn't even a J2EE/Java EE thing: it's a web app
    thing right across the board.

    For your other problem, since the resource locations aren't changing,
    and you are using Faces (Facelets), you have access to JSF EL implicit
    objects. In a situation like this I use (off the top of my head)

    #{facesContext.externalContext.requestContextPath}

    so for example

    #{facesContext.externalContext.requestContextPath}/rsrc/css/style.css

    AHS
     
    Arved Sandstrom, May 23, 2011
    #6
  7. markspace

    Lew Guest

    jebblue wrote:
    > Lew wrote:
    >> <h:eek:utputStylesheet name="/css/purrtones.css" />


    > purrtones? Is this CSS for the late evenings... :)


    Duncan is a debonair orange tabby cat, and the PurrTones are his Motown-style
    singing group. Mrrreow!

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 24, 2011
    #7
  8. On 2011-05-23 15:11:32 -0400, markspace said:

    > Hi all,
    >
    > I'm delving more heavily into JSP/Servlets and JSF at the moment. I've
    > found something that looks like a questionable design issue by the JEE
    > folks at Sun (now Oracle, of course) and I'd like to pick your brains
    > about how you might deal with it.
    >
    > Basically, when developing a JEE web app, the application name gets
    > inserted into every URL and associated path. If my app is named
    > TechDarwinia, for example, then all URLS look like this:
    >
    > http://localhost:8080/TechDarwinia/
    > http://localhost:8080/TechDarwinia/faces/readPost.xhtml
    > http://localhost:8080/TechDarwinia/rsrc/css/style.css
    >
    > The problem is of course that the web app could be renamed anything by
    > the deployer/sysop, and I've got strings hard coded to that app name
    > TechDarwinia.
    >
    > So how do folks write their apps so that they can handle being deployed
    > under different names?


    <c:url> and equivalent tools that inspect the actual context path (the
    "/TechDarwinia/" part of your URL) for the request, largely.

    -o
     
    Owen Jacobson, May 24, 2011
    #8
  9. markspace

    markspace Guest

    On 5/23/2011 2:02 PM, Lew wrote:

    > <h:eek:utputStylesheet name="/css/purrtones.css" />



    Thanks for pointing this out. I was using a regular <link> attribute.
    Those don't seem to be translated or affected by the JSF processing at
    all, and just emit their HTML literally. The h:eek:utputStylesheet looks
    more sophisticated.

    I found a website which explains a bit more:

    <http://blogs.oracle.com/rlubke/entry/jsf_2_0_new_feature4>

    I've got _Java Server Faces 2.0_, by Ed Burns et al, pub. McGraw-Hill.
    Ed Burns was apparently the spec co-lead for JSF 2.0, and I have to say
    I'm not impressed by his book. His section on templates uses raw HTML
    <link> attributes just like I did, and the whole book barely mentions
    h:eek:utputStylesheet. It's only touched on once in the listing of the
    entire component library, which is a pretty unpedagogical way of
    presenting it.

    The Burns book also says that h:eek:utputStylesheet looks for its resources
    under the /resources directory in the application root. Since you're
    plainly specifying a different location, I'm going to have to explore
    resource resolution here a bit more to figure out what the full story is.

    Thanks again for getting me pointed in the right direction.
     
    markspace, May 24, 2011
    #9
  10. markspace

    Tom Anderson Guest

    On Mon, 23 May 2011, markspace wrote:

    > So how do folks write their apps so that they can handle being deployed
    > under different names?


    Just to add to what others have said, the ground truth value for the path
    at which your app is located is HttpServletRequest.getContextPath:

    http://download.oracle.com/javaee/6/api/javax/servlet/http/HttpServletRequest.html#getContextPath()

    Having access to that lets you programmatically construct URLs of various
    kinds (absolute, host-relative, etc). That's how various things, like
    c:url, get this right.

    It doesn't help you deal with this in resources which are not
    programmatic, like static CSS, so here you have to depend on relative
    references. This doesn't strike me as difficult - you decide early on to
    keep all your css under /contextpath/css, and your site furniture images
    under /contextpath/images, and then because CSS image paths are relative
    to the stylesheet, in your CSS you can write:

    background:url(../images/bbg.jpg) left top repeat;

    A similar approach should be usable in other static resources which
    contain links.

    tom

    --
    Just because Congresspeople do it, doesn't mean it's right. -- Ian York
     
    Tom Anderson, May 24, 2011
    #10
  11. markspace

    markspace Guest

    On 5/24/2011 10:16 AM, Tom Anderson wrote:
    >
    > It doesn't help you deal with this in resources which are not
    > programmatic, like static CSS, so here you have to depend on relative
    > references. This doesn't strike me as difficult - you decide early on to
    > keep all your css under /contextpath/css, and your site furniture images
    > under /contextpath/images, and then because CSS image paths are relative
    > to the stylesheet, in your CSS you can write:
    >
    > background:url(../images/bbg.jpg) left top repeat;



    Thanks for replying Tom, but this doesn't appear to be quite correct.
    According to some sources on the 'net, you CAN put EL expressions in
    static CSS resources:

    background:url("#{resource['sunny:images/header.png']}")

    <http://primefaces.prime.com.tr/forum/viewtopic.php?f=3&t=3774&start=0>

    <link type="text/css" rel="stylesheet"
    href="#{request.contextPath}/css/theme/login.css" />

    <http://forums.oracle.com/forums/thread.jspa?threadID=1717161&tstart=-2&messageID=7177962>

    This works because apparently when you load with a Faces tag like
    h:eek:utputStylesheet, it emits HTML that loads the static resource through
    the Faces servlet. For example, this:

    <h:eek:utputStylesheet name="css/login.css" />

    renders as this:

    <link type="text/css" rel="stylesheet"
    href="/solicitacoes/javax.faces.resource/css/login.css.xhtml" />

    where "solicitacoes" is apparently the web context root.

    <http://forums.oracle.com/forums/thread.jspa?threadID=1717161&tstart=-2&messageID=7177962>


    I really appreciated you guys trying to help me out, but I'm really
    frustrated at the lack of a single, authoritative source where all this
    is spelled out. I looked in the JSF 2.1 spec and it barely even
    mentions h:eek:utputStylesheet, and certainly doesn't discuss its tags or
    parameters anywhere that I could find.
     
    markspace, May 25, 2011
    #11
  12. markspace

    markspace Guest

    On 5/25/2011 12:16 PM, markspace wrote:

    > Thanks for replying Tom, but this doesn't appear to be quite correct.
    > According to some sources on the 'net, you CAN put EL expressions in
    > static CSS resources:
    >
    > background:url("#{resource['sunny:images/header.png']}")



    And what's more is those resources from the CSS file will themselves be
    fetched through the Faces servlet. This:

    body {
    background:url("#{resource['img/bbg.jpg']}") left top repeat;
    color:#555555;
    font-size:11px;
    font-family:Tahoma, Arial;
    padding:0px 0px 0px 0px;
    margin:0px 0px 0px 0px;
    }


    gets transmorgified to this:


    body {
    background:url("/TechDarwinia/faces/javax.faces.resource/img/bbg.jpg")
    left top repeat;
    color:#555555;
    font-size:11px;
    font-family:Tahoma, Arial;
    padding:0px 0px 0px 0px;
    margin:0px 0px 0px 0px;
    }
     
    markspace, May 26, 2011
    #12
  13. markspace

    Tom Anderson Guest

    On Wed, 25 May 2011, markspace wrote:

    > On 5/24/2011 10:16 AM, Tom Anderson wrote:
    >>
    >> It doesn't help you deal with this in resources which are not
    >> programmatic, like static CSS, so here you have to depend on relative
    >> references. This doesn't strike me as difficult - you decide early on
    >> to keep all your css under /contextpath/css, and your site furniture
    >> images under /contextpath/images, and then because CSS image paths are
    >> relative to the stylesheet, in your CSS you can write:
    >>
    >> background:url(../images/bbg.jpg) left top repeat;

    >
    > Thanks for replying Tom, but this doesn't appear to be quite correct.
    > According to some sources on the 'net, you CAN put EL expressions in
    > static CSS resources: [...] This works because apparently when you load
    > with a Faces tag like h:eek:utputStylesheet, it emits HTML that loads the
    > static resource through the Faces servlet.


    In which case it's not static CSS! Anything that gets mangled by code
    before being served is dynamic, and is able to evade this problem.

    > I really appreciated you guys trying to help me out, but I'm really
    > frustrated at the lack of a single, authoritative source where all this
    > is spelled out. I looked in the JSF 2.1 spec and it barely even mentions
    > h:eek:utputStylesheet, and certainly doesn't discuss its tags or parameters
    > anywhere that I could find.


    So the "all this" you'd like to see spelled out is JSF? I can't comment -
    i have never used JSF, and have absolutely no desire to. I'm surprised and
    disappointed to hear that JSF is poorly documented, since it's a flagship
    J2EE technology. I think the servlet and JSP specs (i'm thinking of
    javadocs, actually) do explain their parts of this reasonably well, FWIW.

    tom

    --
    .... which may end up with the women in your office cornering you at the
    office xmas party and taking turns at jamming their bootclad feet into
    your genitals. This is what is known as the Wrong Kind of Footsie. --
    Lord Foom
     
    Tom Anderson, May 26, 2011
    #13
  14. markspace

    Lew Guest

    Tom Anderson wrote:
    > So the "all this" you'd like to see spelled out is JSF? I can't comment - i
    > have never used JSF, and have absolutely no desire to. I'm surprised and
    > disappointed to hear that JSF is poorly documented, since it's a flagship J2EE
    > technology. I think the servlet and JSP specs (i'm thinking of javadocs,
    > actually) do explain their parts of this reasonably well, FWIW.


    I've been able to work out "all this" pretty much from
    http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
    the MyFaces docs and the articles in IBM DeveloperWorks.

    I don't know of any technology, Javas, C#, SQL or what-have-you, that is fully
    documented in a perfect way for every practitioner in a single source.

    JSF is simply a wonderful framework.

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 26, 2011
    #14
  15. markspace

    markspace Guest

    On 5/26/2011 10:07 AM, Tom Anderson wrote:
    >
    > In which case it's not static CSS! Anything that gets mangled by code
    > before being served is dynamic, and is able to evade this problem.



    Well, true, I was just surprised that JSF was capable of taking a
    resource that looked like it should be static and treating it dynamically.
     
    markspace, May 26, 2011
    #15
  16. markspace

    markspace Guest

    On 5/26/2011 10:25 AM, Lew wrote:

    > I've been able to work out "all this" pretty much from
    > http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
    > the MyFaces docs and the articles in IBM DeveloperWorks.



    Thanks for pointing out those additional resources. I think right now
    I'm mostly concerned that the JSF 2.1 spec seems a lot less complete
    than the JSP and Servlet one, and that the book I purchased by the spec
    co-lead seems equally abbreviated. You'd think Sun (and now Oracle)
    would be most interested in making sure that accurate and complete
    documentation is available. "Google for it and read some blogs" seems
    like the opposite of that idea.

    Don't mind me though, I'm typical grumpy when I'm trying to plow my way
    through new concepts.
     
    markspace, May 26, 2011
    #16
  17. markspace

    Lew Guest

    markspace wrote:
    > Lew wrote:
    >> I've been able to work out "all this" pretty much from
    >> http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
    >> the MyFaces docs and the articles in IBM DeveloperWorks.


    > Thanks for pointing out those additional resources. I think right now I'm


    I forgot to mention the most important one: lots of example apps that I
    created in my (copious) spare time. I went nuts in JSF 1.something when
    "rendered='false'" on first page call would prevent a component from being in
    the tree, never to be reinserted in postback when the value flipped to 'true'.
    They fixed that later. I went nuts overall until I began to grok the
    six-stage component lifecycle of JSF. I went nuts until I learned that every
    backing bean is a controller, unlike the front-controller pattern familiar to
    Model 2 and Struts mavens. I still don't use "immediate='true'".

    I must've tried every variation of URL in JSF, JSTL, jsp:useBean and such
    structures as I've learned my J{2,ava }EE skills in order to learn where
    things need to be for the app server to find them. I still am not fully aware
    of the nuances.

    > mostly concerned that the JSF 2.1 spec seems a lot less complete than the JSP
    > and Servlet one, and that the book I purchased by the spec co-lead seems
    > equally abbreviated. You'd think Sun (and now Oracle) would be most interested
    > in making sure that accurate and complete documentation is available. "Google
    > for it and read some blogs" seems like the opposite of that idea.
    >
    > Don't mind me though, I'm typically grumpy when I'm trying to plow my way
    > through new concepts.


    Curmudgeons of the world, uni- - - ah, screw it!

    If programming was easy, anyone could do it. Sometimes you just have to bang
    your (metaphorical) head against the (metaphorical) brick walls until
    something (hopefully the wall) crumbles (metaphorically). And I truly found
    that GIMF through all that with JSF.

    --
    Lew
     
    Lew, May 27, 2011
    #17
  18. On 11-05-26 08:39 PM, Lew wrote:
    > markspace wrote:
    >> Lew wrote:
    >>> I've been able to work out "all this" pretty much from
    >>> http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
    >>> the MyFaces docs and the articles in IBM DeveloperWorks.

    >
    >> Thanks for pointing out those additional resources. I think right now I'm

    >
    > I forgot to mention the most important one: lots of example apps that I
    > created in my (copious) spare time. I went nuts in JSF 1.something when
    > "rendered='false'" on first page call would prevent a component from
    > being in the tree, never to be reinserted in postback when the value
    > flipped to 'true'. They fixed that later. I went nuts overall until I
    > began to grok the six-stage component lifecycle of JSF.


    I similarly went nuts in my early exposure to JSF until I learnt that
    lifecycle. I lived by Rick Hightower and BalusC. These days I go nuts
    because I work with people who have had to use JSF for the same length
    of time as me, but who haven't bothered to learn the lifecycle, and
    screw coding up because of it.

    Typical problem - people not realizing how often getters get called in
    first view or postback, and jamming all sorts of unguarded persistence
    operations into getters as a result. "Duhhhhh...why did that table get
    updated twice?"

    > I went nuts
    > until I learned that every backing bean is a controller, unlike the
    > front-controller pattern familiar to Model 2 and Struts mavens.


    One other thing to learn early on is the distinction between JSF managed
    beans and JSF backing beans. Many of the same aforementioned people use
    the terms indistinguishably, and I wish they wouldn't. No excuse for
    this confusion: the Java EE tutorial explains the difference clearly in
    2 sentences.

    I like the (newish) CDI annotations that allow the "managing" bit -
    naming and scoping, for starters - not to be a JSF thing. I use them
    when I can.

    For my own amusement I dissected the JSF controller behaviour some years
    ago. With reference to Fowler's P of EAA stuff, there are aspects of
    both front and page controllers in JSF. To be pedantic, I'd argue that
    it's still more Front controller than Page controller: the FacesServlet
    actually handles the requests. The getters/setters in a JSF backing bean
    that are associated with UI components only process a request meant for
    them in a rather anemic, last-mile way. And the actions in a backing
    bean are akin to the command objects inherent in Front Controller.
    FacesServlet handles the navigation also.

    If someone makes a Page Controller argument for JSF, and that's been
    done more than once, I won't get bent out of shape because of it. One
    one level of abstraction the JSF beans look like page controllers. As
    long as one understands the mechanics that's fine. But I personally
    really think it's still Front Controller.

    > I still
    > don't use "immediate='true'".


    I almost never use it either now. The reason I don't is because it takes
    some quality reading to understand what "immediate" does (see the
    excellent description at
    http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works), and
    you have to re-read and refresh yourself on that every few months when
    your use of "immediate" has caused a bug (or more likely, some other
    developer never read up on it and uses "immediate" incorrectly, and
    you've got to fix the defect).

    It's just not worth it.

    > I must've tried every variation of URL in JSF, JSTL, jsp:useBean and
    > such structures as I've learned my J{2,ava }EE skills in order to learn
    > where things need to be for the app server to find them. I still am not
    > fully aware of the nuances.


    Other takeaways: thank God for Facelets. I haven't used JSPs in 3 years.
    And even though it's got better support in JSF 1.2 and 2.0 than it did
    in 1.1, _don't_ mix JSTL and JSF. If you're writing JSF JSPs or
    Facelets, and you think you need JSTL, think again - you don't.

    >> mostly concerned that the JSF 2.1 spec seems a lot less complete than
    >> the JSP
    >> and Servlet one, and that the book I purchased by the spec co-lead seems
    >> equally abbreviated. You'd think Sun (and now Oracle) would be most
    >> interested
    >> in making sure that accurate and complete documentation is available.
    >> "Google
    >> for it and read some blogs" seems like the opposite of that idea.
    >>
    >> Don't mind me though, I'm typically grumpy when I'm trying to plow my way
    >> through new concepts.

    >
    > Curmudgeons of the world, uni- - - ah, screw it!
    >
    > If programming was easy, anyone could do it. Sometimes you just have to
    > bang your (metaphorical) head against the (metaphorical) brick walls
    > until something (hopefully the wall) crumbles (metaphorically). And I
    > truly found that GIMF through all that with JSF.
    >

    I am reasonably fond of both JSF (especially JSF 2.0) and ASP.NET MVC.
    As far as I am concerned both teams got It.

    AHS
     
    Arved Sandstrom, May 27, 2011
    #18
  19. markspace

    Lew Guest

    Arved Sandstrom wrote:
    > Lew wrote:
    >> markspace wrote:
    >>> Lew wrote:
    >>>> I've been able to work out "all this" pretty much from
    >>>> http://download.oracle.com/javaee/6/tutorial/doc/bnadp.html
    >>>> the MyFaces docs and the articles in IBM DeveloperWorks.


    >>> Thanks for pointing out those additional resources. I think right now I'm


    >> I forgot to mention the most important one: lots of example apps that I
    >> created in my (copious) spare time. I went nuts in JSF 1.something when
    >> "rendered='false'" on first page call would prevent a component from
    >> being in the tree, never to be reinserted in postback when the value
    >> flipped to 'true'. They fixed that later. I went nuts overall until I
    >> began to grok the six-stage component lifecycle of JSF.


    > I similarly went nuts in my early exposure to JSF until I learnt that
    > lifecycle. I lived by Rick Hightower and BalusC. These days I go nuts
    > because I work with people who have had to use JSF for the same length
    > of time as me, but who haven't bothered to learn the lifecycle, and
    > screw coding up because of it.
    >
    > Typical problem - people not realizing how often getters get called in
    > first view or postback, and jamming all sorts of unguarded persistence
    > operations into getters as a result. "Duhhhhh...why did that table get
    > updated twice?"


    Boy, that was a surprise the first time I encountered it AT HOME WHILE I WAS
    PRACTICING!

    Then I studied up and found out about the lifecycle.

    All before I accepted a paycheck to do JSF programming. Not that I needed to
    be a master first, but I sure needed to do SOME practice first.

    >> I went nuts
    >> until I learned that every backing bean is a controller, unlike the
    >> front-controller pattern familiar to Model 2 and Struts mavens.


    > One other thing to learn early on is the distinction between JSF managed
    > beans and JSF backing beans. Many of the same aforementioned people use
    > the terms indistinguishably, and I wish they wouldn't. No excuse for
    > this confusion: the Java EE tutorial explains the difference clearly in
    > 2 sentences.


    This one I had not encountered, maybe because backing beans were first in the
    managed-bean universe and managed beans were generalized therefrom:
    <http://download.oracle.com/javaee/6/tutorial/doc/bnacj.html#indexterm-85>
    "Managed Beans represent a generalization of the managed beans specified by
    JavaServer Faces technology and can be used anywhere in a Java EE application,
    not just in web modules."

    I see from
    <http://download.oracle.com/javaee/6/tutorial/doc/gjaam.html#gjacb>
    "As mentioned earlier in this chapter, a backing bean, a type of managed bean,
    is a JavaBeans component that is managed by JavaServer Faces technology.
    Components in a page are associated with backing beans that provide
    application logic."

    However, managed beans are actually not defined earlier in that chapter.

    <http://download.oracle.com/javaee/6/tutorial/doc/bnaqm.html>
    "A typical JavaServer Faces application includes one or more backing beans,
    each of which is a type of JavaServer Faces managed bean that can be
    associated with the components used in a particular page."

    In any case, I couldn't find the "two sentences" to which you refer, so I
    suggest you lighten up a little on that particular rigidity.

    > I like the (newish) CDI annotations that allow the "managing" bit -
    > naming and scoping, for starters - not to be a JSF thing. I use them
    > when I can.
    >
    > ... [snip ...


    >> I still
    >> don't use "immediate='true'".


    > I almost never use it either now. The reason I don't is because it takes
    > some quality reading to understand what "immediate" does (see the
    > excellent description at
    > http://wiki.apache.org/myfaces/How_The_Immediate_Attribute_Works), and
    > you have to re-read and refresh yourself on that every few months when
    > your use of "immediate" has caused a bug (or more likely, some other
    > developer never read up on it and uses "immediate" incorrectly, and
    > you've got to fix the defect).
    >
    > It's just not worth it.


    You echo my reasoning. Hard to understand, limited usefulness - screw it.

    >> I must've tried every variation of URL in JSF, JSTL, jsp:useBean and
    >> such structures as I've learned my J{2,ava }EE skills in order to learn
    >> where things need to be for the app server to find them. I still am not
    >> fully aware of the nuances.


    > Other takeaways: thank God for Facelets. I haven't used JSPs in 3 years.
    > And even though it's got better support in JSF 1.2 and 2.0 than it did
    > in 1.1, _don't_ mix JSTL and JSF. If you're writing JSF JSPs or
    > Facelets, and you think you need JSTL, think again - you don't.


    I've seen this mistake in practice, and people (so-called "programmers", no
    less!) look at me blankly when I give that advice. And yet they're never the
    ones to get fired!

    >>> mostly concerned that the JSF 2.1 spec seems a lot less complete than
    >>> the JSP
    >>> and Servlet one, and that the book I purchased by the spec co-lead seems
    >>> equally abbreviated. You'd think Sun (and now Oracle) would be most
    >>> interested in making sure that accurate and complete documentation is available.
    >>> "Google for it and read some blogs" seems like the opposite of that idea.
    >>>
    >>> Don't mind me though, I'm typically grumpy when I'm trying to plow my way
    >>> through new concepts.

    >>
    >> Curmudgeons of the world, uni- - - ah, screw it!
    >>
    >> If programming was easy, anyone could do it. Sometimes you just have to
    >> bang your (metaphorical) head against the (metaphorical) brick walls
    >> until something (hopefully the wall) crumbles (metaphorically). And I
    >> truly found that GIMF through all that with JSF.
    >>

    > I am reasonably fond of both JSF (especially JSF 2.0) and ASP.NET MVC.
    > As far as I am concerned both teams got It.


    Yay, facelets!

    Boo, ignorance!

    --
    Lew
    Honi soit qui mal y pense.
    http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg
     
    Lew, May 27, 2011
    #19
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Craig
    Replies:
    0
    Views:
    459
    Craig
    Feb 9, 2004
  2. Frank Langelage
    Replies:
    2
    Views:
    337
    Frank Langelage
    Jul 2, 2006
  3. Naeem
    Replies:
    1
    Views:
    306
  4. Naeem
    Replies:
    0
    Views:
    276
    Naeem
    Apr 15, 2007
  5. Tim Slattery

    Eclipse JEE application

    Tim Slattery, May 3, 2011, in forum: Java
    Replies:
    5
    Views:
    1,564
Loading...

Share This Page