Article: Web Apps with Struts, Tiles and JavaServer Faces

Discussions

News: Article: Web Apps with Struts, Tiles and JavaServer Faces

  1. There is a new article on IBM developer works which discusses writing web applications using the holy trinity of Struts, Tiles and JavaServer Faces together. The article talks about why you would want to do this, migrating Stuts applications to this new model, and the challenges.

    "Would you like the front-end power of JavaServer Faces (JSF), the content-formatting strengths of Tiles, and the flexibility of the Struts controller tier all wrapped up in your J2EE Web application? Enterprise Java experts Srikanth Shenoy and Nithin Mallya show you how to integrate the features of all three. This article demonstrates how to customize the classes in the Struts-Faces integration library to make them work with Tiles and JSF, explains the rationale behind doing this, and details how to use the new set of classes with a working example."

    View the article: Integrating Struts, Tiles, and JavaServer Faces

    PS: The Struts-Faces integration library download link in the article does not work. Looks like it has moved since this was written.

    Struts-Faces is now available at http://archive.apache.org/dist/jakarta/struts/old/release/struts-faces/

    Threaded Messages (17)

  2. Great article for it's brevity, clarity and concept. I am thinking that the complexity of proposed combination of Struts-JSF-Tiles outweight the advantages by a very big margin. How much percentage of Java based web application are using Struts ? If it is max. 25%, I can say most of them want to go for Struts-JSF combo for migrating some of the pages, may be because they have lot of eventing logic used in them, may be because that is the writing on the wall. But add the Tiles component to it. I hardly see any body want to go for that extra complexity for the benefits of flexible layouts.

    How about portals ? I mean the combination of Struts-JSF with portals. You get lot different environment of portals, with all it's manageability, life cycle, independence, modularity etc. I have been working in SAP R/3's enterprise portals area, where SAP already has provided a implementation of JSF-type custom tags to be used in combination with portal API. The same thing can be done with in J2EE too. Right ? Try to integrate portlet API(JSR 168) with JSF custom tags, you get benefit of both worlds !

    Just my 2 cents...

    Prasad Nutalapati
  3. Complexity v/s maintainability[ Go to top ]

    Great article for it's brevity, clarity and concept. I am thinking that the complexity of proposed combination of Struts-JSF-Tiles outweight the advantages by a very big margin. How much percentage of Java based web application are using Struts ? If it is max. 25%, I can say most of them want to go for Struts-JSF combo for migrating some of the pages, may be because they have lot of eventing logic used in them, may be because that is the writing on the wall. But add the Tiles component to it. I hardly see any body want to go for that extra complexity for the benefits of flexible layouts.

    >

    I dont know the stats, however even if 25% of the industry is using Struts as the web application framework, it is quite a bit. JSF is the natural transition for projects using Struts and Struts-Faces bridges that gap quite well.

    In the contemporary industry, unfortunately jsp front end is not designed, just coded. And so jsps start as monolithic pieces. Soon the need for reuse comes up and the path usually taken is jsp includes (static or dynamic). Very soon you have layouts, styles and formatting for the pages spread across the entire system. Even if you use CSS, there are that many places to change as the number of pages in the system.

    With just a bit of upfront design the layout can be centralized for better control. It maybe the case that not many folks are doing it, while they should be, ideally.

    The code in the article indeed looks complex ;-D, since there are a lot of gotchas to handle. An alternative is to take the route of treating it more or less as a blackbox and use it. It works!!

    I definitely cannot speak on behalf the Struts project, but I think this code will make it to the next version of Struts-Faces. When that happens, you don't have to worry about all these complexities. It will be available for you out-of-the-box.

    > How about portals ? I mean the combination of Struts-JSF with portals. You get lot different environment of portals, with all it's manageability, life cycle, independence, modularity etc. I have been working in SAP R/3's enterprise portals area, where SAP already has provided a implementation of JSF-type custom tags to be used in combination with portal API. The same thing can be done with in J2EE too. Right ? Try to integrate portlet API(JSR 168) with JSF custom tags, you get benefit of both worlds !
    >
    > Just my 2 cents...


    The portal containing the portlets will require a template and layout. Albeit its manageability and elegance, sure enough there will be non-portlet apps mixed with portlets in your web site. What I mean is that there is a case for Tiles (or Tiles-like) framework for any web site.

    I dont know much about Portlets, so I cannot really speak about integrating Portlet API and JSF Custom Tags. I think that should be easy enough. May be somebody can shed some light.

    Cheers,
    -Srikanth Shenoy
  4. Simple?[ Go to top ]

    A "simple" JSF form from the article is listed below. Good luck to any graphic designers who need to touch up the UI in this form. I really don't see how this can be considered an improvement for building views. When I see XML used like this for programming, I gag. Do people really want to program like this?

    <f:use_faces>
     <h:form id="flightForm" formName="flightForm" >
       <h:input_text id="fromCity" valueRef="FlightSearchBean.fromCity">
       <f:validate_required/>
       <h:input_text/>

       <h:input_text id="toCity" valueRef="FlightSearchBean.toCity">
       <h:input_text id="departureDate"
         valueRef="FlightSearchBean.departureDate">
       <h:input_text id="arrivalDate"
         valueRef="FlightSearchBean.arrivalDate">

       <h:command_button id="submit" action="success"
         label="Submit" commandName="submit" >
           <f:action_listener
             type="foo.bar.FlightSearchActionListener"/>
       </h:command_button>
       <h:command_button id="reset" action="reset" label="Reset"
         commandName="reset" />

       <h:output_errors/>
     </h:form>
    </f:use_faces>
  5. Simple?[ Go to top ]

    When I see XML used like this for programming, I gag.

    > Do people really want to program like this?

    You mean as opposed to (?):

    <html>
    <head>
    <title>Joke</title>
    </head>
    <body>
    Look familiar?
    </body>
    </html>

    Okay, so that isn't programming (smile), but realistically, the benefit of markup presentation tiers, whether it be HTML, ASP.NET, JSF or something similar, really lend themselves to tools quite nicely. We all know that many code generation tools can be sloppy (esp. in the presentation tier), but that task is simplified greatly when you shift to markup.

    Would it be a bad thing if designers could use a tool like Dreamweaver to layout/design a JSF application, and you could add the logic independently? For a reference implementation you don't have to look any further than ASP.NET and Visual Studio. I think that the real goal is of course in trying to distinctly separate the presentation such that we Java developers don't even have to think about it (program it) at all.
  6. Simple?[ Go to top ]

    Okay, so that isn't programming (smile), but realistically, the benefit of markup presentation tiers, whether it be HTML, ASP.NET, JSF or something similar, really lend themselves to tools quite nicely.

    And we're free to invent a simpler XML dialect and then create a reusable XSL stylesheet that translates it to JSF. That would make text maintenance easy enough.
  7. Simplicity is relative[ Go to top ]

    Consider th two listings below - And you decide which is better.

    Listing 1.
    <f:use_faces>
    <s:errors/>
    <s:form action="/saveRegistration" focus="username"
             onsubmit="return validateRegistrationForm(this);">

      <h:input_hidden id="action" valueRef="registrationForm.action"/>

      <h:panel_grid columns="2" panelClass="form-background"
                    headerClass="form-header"
                    columnClasses="form-prompt,form-field">

        <f:facet name="header">
          <h:panel_group>
            <s:message key="registration.header.create"/>
          </h:panel_group>
        </f:facet>

        <h:output_label for="username">
          <s:message key="prompt.username"/>
        </h:output_label>

        <h:panel_group>
        <h:input_text id="username" size="16" valueRef="registrationForm.username"/>
        </h:panel_group>

        <h:output_label for="password">
          <s:message key="prompt.password"/>
        </h:output_label>

        <h:input_text id="password"
            size="16" valueRef="registrationForm.password"/>

        <h:command_button id="submit" type="SUBMIT" commandName="submit"
                commandClass="command-single"
                       label="Save"/>

        <h:panel_group>
          <h:command_button id="reset" type="RESET" commandName="reset"
                  commandClass="command-multiple"
                         label="Reset"/>
          <h:command_button id="cancel" type="SUBMIT" commandName="cancel"
                  commandClass="command-multiple"
                         label="Cancel"/>
        </h:panel_group>

      </h:panel_grid>

    </s:form>
    </f:use_faces>

                                 OR THIS

    Listing 2.
    <form name="registrationForm" method="post" action="/struts-faces/faces/registration.jsp" onsubmit="return validateRegistrationForm(this);">
    <input type="hidden" name="org.apache.struts.taglib.html.TOKEN" value="df68b6076d373447c4129251a3fd1127">

    <input type="hidden" name="action" value="Create">

    <table class="form-background">
    <tr><th class="form-header" colspan="2">Enter Registration Information</th></tr>
    <tr>
    <td class="form-prompt"><label for="username" >
    Username</label></td>
    <td class="form-field"><input type="text" name="username" value="" size="16" ></td>
    </tr>
    <tr>
    <td class="form-prompt"><label for="password" >
    Password</label></td>
    <td class="form-field"><input type="text" name="password" value="" size="16" ></td>
    </tr>
    <tr>
    <td class="form-prompt"><input type="submit" name="submit" value="Save" class="command-single" ></td>
    <td class="form-field"><input type="reset" name="reset" value="Reset" class="command-multiple" ><input type="submit" name="cancel" value="Cancel" class="command-multiple" ></td>
    </tr>
    </table>

    </form>

    The reality is http is painful. It is stretched beyond imagination to accomodate the complexities of today's applications. But there is no other delivery mechanism as prevalant as the browsers and so we have to deal with it.
    That is reality.

    And while we are it, let us at least do a good job and choose the lesser of evils (and devils).
    Ultimately when the front end scripting is standardized, the graphic designers will not be hand coding this. Every IDE will probably have a tool to drag and drop the jsf elements into the virtual page.

    There is nothing to gag about using xml in views. Arent jsp custom tags xml themselves?

    I consider JSF a big leap for mankind... [Well thats a stretch. but you know what I mean... ;-D]

    Cheers,
    Srikanth
  8. Simplicity is relative[ Go to top ]

    I agree that original JSF syntax is verbose.
    But, I hope that 3rd party JSF components/JSF tags will be much less verbose and more simple, readable and elegant to use!!!

    Mileta
  9. Role separation - UI vs serverside[ Go to top ]

    As things progress surely some IDEs will pop up that will abstract all the handcoding of these tags which has been stated before. One thing to note however, as having experienced website that were graphically designed down the the very pixel positioning elements and graphics on the page (imagine a graphic designer kicking up a fuss because the distance between the the form elements is not his specified 12px, or could you move that header 2px up and 5 px to the right), this is where good knowledge of HTML was valuable. Now when you mix this with the serverside programmers who think that HTML is 'easy' and they would not be caught dead spending time on a UI, you find that they dont fully understand how to get the level of precision in a HTML document that a pedantic, graphic designer will need. But at the end of the day, this is what the user will see and hence what they feel they are getting.

    To get back to the point. Hand written HTML is still very widely used and it should not be overshadowed by WYSIWYG drag and drop IDE's that produce shoddy, unmaintainable code. Keep the balance and forget the idea that the front end, because it is a pain in the arse to muck around with, should not be just threw together. There are many companies who use extensive design teams to produce the best UI possible to their clients. UI's that follow usability guidelines and sound graphical design methodologies. And in these cases, the technology is forged around the design, not the front end a 'face' for the implementation of underlying logic

    Now I know that HTML is old also. Struts html tags, JSF and JSTL tags are very, very good for the UI development and a step in the right direction, but you have to remember to keep seperation of roles here. If you dont like UI development,leave it to the group that does. They probably do it well and dont apprecitate a server side developer coming and telling them that they need to use these 'fancy' tags, so that the serverside developer can understand the front end better.

    Also, one last thing. Quicker is not and never will be better than taking your time and getting it right first time...well in IMHO anyhow
  10. Simplicity is relative[ Go to top ]

    Consider th two listings below - And you decide which is better.

    But JSF is not mandatory for the Listing 1. Is not it?
    Any taglib wraps basic HTML stuff is enough

    Dmitry Namiot
    Coldbeans
  11. Simplicity is relative[ Go to top ]

    Well, this is of course just my opinion, but I, and I imagine every graphic designer I've had to work with, greatly prefer #2. I'm also biased because I'm a Velocity convert who tries to avoid JSP tags at all costs. When the customer asks for certain UI changes during the project, how can a graphic designer work with #1? Yes, the form tag looks messy, but a graphic designer doesn't need to fool with that if he/she needs to change the UI. And as previously mentioned, most graphic designers want complete control over tags and tag attributes, and I just don't see how you can go from the markup that a designer generates to what's shown in listing #1.

    You mention "when the front end scripting is standardized"... yes, that would be nice, but really, how close are we to that? I haven't seen what Dreamweaver can do recently, and I'm probably begging for Gerald Bauer to make a XUL pitch as the solution for replacing HTML, but in JSF, I only see more headaches in trying to share the UI between designers and programmers.

    Rob
  12. Simplicity is relative[ Go to top ]

    Well, this is of course just my opinion, but I, and I imagine every graphic designer I've had to work with, greatly prefer #2. I'm also biased because I'm a Velocity convert who tries to avoid JSP tags at all costs. When the customer asks for certain UI changes during the project, how can a graphic designer work with #1? Yes, the form tag looks messy, but a graphic designer doesn't need to fool with that if he/she needs to change the UI. And as previously mentioned, most graphic designers want complete control over tags and tag attributes, and I just don't see how you can go from the markup that a designer generates to what's shown in listing #1.

    >

    With JSF, it will be possible (almost mandatory) to have graphic editors generate JSF tags, the same way graphic designers create the html interface today. It´s like having dreamweave generate JSF files instead of html files. These designers wont have to fiddle with the JSF code in files themselves, they will work with visual tools. The server-side code will reside in a different file, thus creating an independence between the design team and the developers.

    > You mention "when the front end scripting is standardized"... yes, that would be nice, but really, how close are we to that? I haven't seen what Dreamweaver can do recently, and I'm probably begging for Gerald Bauer to make a XUL pitch as the solution for replacing HTML, but in JSF, I only see more headaches in trying to share the UI between designers and programmers.
    >
    > Rob

    The UI won't have to be shared. One file will contain the JSF code, and another will have the code. So the designers will be able to play with the interface as much as they need/want, and the developers will be able to code as much as they need/want, even using different tools for each task.
  13. Simplicity is relative[ Go to top ]

    Okay, well, I think there's definitely some Kool-Aid to drink here regarding the idea that designers will use tools to generate JSF tags. I know designers use nice tools like Dreamweaver to do the upfront GUI work, but they usually have to resort to manually tweaking HTML to get things just right. I would think that once we see a Dreamweaver-like tool to generate JSF tags, the designers would still need to tweak the code manually, in this case tweaking JSF tags as opposed to HTML. But then designers are required to be fluent with JSF tags (or an XML equivalent, as mentioned previously, which can be XSLT'ed to JSF). But hey, if it turns out that these future tools work well and they allow designers to do their thing, and no one has to hand-poke HTML for hours on end, I'll be happy. But I'll believe it when I see it.

    There's still the reality that JSF code is absolutely awful to look at, but perhaps that will hasten the development of JSF-authoring tools.

    Rob
  14. Okay, well, I think there's definitely some Kool-Aid to drink here regarding the idea that designers will use tools to generate JSF tags. I know designers use nice tools like Dreamweaver to do the upfront GUI work, but they usually have to resort to manually tweaking HTML to get things just right. I would think that once we see a Dreamweaver-like tool to generate JSF tags, the designers would still need to tweak the code manually, in this case tweaking JSF tags as opposed to HTML. But then designers are required to be fluent with JSF tags (or an XML equivalent, as mentioned previously, which can be XSLT'ed to JSF). But hey, if it turns out that these future tools work well and they allow designers to do their thing, and no one has to hand-poke HTML for hours on end, I'll be happy. But I'll believe it when I see it.

    >
    > There's still the reality that JSF code is absolutely awful to look at, but perhaps that will hasten the development of JSF-authoring tools.
    >

    > Rob

    Rob,

    It is very clear from your posts that you have been in the trenches and understand what the frustration is all about from the page authors point of view.

    But I think you are missing one point here.
    Page authors need not tweak the JSF page as they used to with the html pages
    Instead, any tweaking in terms of adjusting the width of the table, color, border, fitting into the screen goes into the CSS.
    In fact JSF almost mandates the use of CSS.

    Now, I think you will appreciate the power of JSF.
    Page authors need not tweak the auto-generated JSF tags.
    They will be rather tweaking the CSS, which all page authors are adept at.

    As you know, J2EE defines the various roles. But some cons of that role defintion was a single deployment artifact ( read JSP) required manipulations from different roles (page authors, component developers, application programmers) resulting in various roles stepping on each others toes.

    JSF will probably change that.
    In other words, JSF makes the distinction between J2EE defined roles clearer without overlap of role defined tasks overlapping in the artifacts - meaning one role one artifact.

    Cheers,
    Srikanth
  15. Page authors need not tweak the auto-generated JSF tags. They will be rather tweaking the CSS, which all page authors are adept at.

    Excellent. But still the graphics designer person likely needs to read the JSF to learn how the CSS properties are used. Ie, doesn't he have to mentally reverse engineer the JSF just to understand stylesheet maintenance?
  16. I'm thinking in making use of Xkins framework (http://xkins.sourceforge.net/) in order to produce HTML by JSF UIComponents. This would allow me to put HTML code outside Java code (in an XML file) and allow multiple look&feel in a same web application (if needed). You could have several skins for applications using JSF. Xkin's last version allows me to have a single directory containing both templates and images and allows me to use Velocity to produce html, so you can distribute skins independently.
    Using this schema doesnt requires CSS usage because you simply can change the Skin template in order to produce a diferent look for the UIComponent, and not only in color, font, size, but also in layout and morphology (think in buttons as INPUT TYPE BUTTON or in a A HREF with an image or a INPUT TYPE IMAGE).
  17. Layout[ Go to top ]

    What gives jsf an advantage over Struts layout?
  18. Tiles is complex?[ Go to top ]

    Great article for it's brevity, clarity and concept. I am thinking that the complexity of proposed combination of Struts-JSF-Tiles outweight the advantages by a very big margin. How much percentage of Java based web application are using Struts ? If it is max. 25%, I can say most of them want to go for Struts-JSF combo for migrating some of the pages, may be because they have lot of eventing logic used in them, may be because that is the writing on the wall. But add the Tiles component to it. I hardly see any body want to go for that extra complexity for the benefits of flexible layouts.

    >

    Tiles is complex you say? Sorry, this is not my experience *at all* if anything Tiles is the simplest part of the Struts toolkit. Look at this Tiles config and tell me you can't figure out what its doing:

      <definition name="doc.mainLayout" path="/template/classicLayout.jsp">
        <put name="title" value="Title"/>
        <put name="header" value="/template/header.jsp"/>
        <put name="menu" value="/template/menu.jsp"/>
        <put name="footer" value="/template/footer.jsp"/>
        <put name="body" value="/template/main.jsp"/>
      </definition>

    Now that's not too hard to understand is it?