There has been a pretty good discussion on JavaRanch about JSF recently and the original poster was a bit dismayed at JSF's current state. Several alternatives were suggested as well as proponents for JSF jumping in claiming that JSF is "good enough". It's Interesting that a lot of the comments from JSF proponents in several threads I've been keeping an eye on were things like "...it has it's issues but..." and "...a workaround for that is...".

I try and suggest Stripes as much as I can. Since I stumbled on Stripes, I've found it to be the best all around framework for my purposes. Yes, my purposes. I don't pretend to think that Stripes is the end all solution in the saturated domain of JEE Frameworks, but if I see someone asking for a solution to a problem, and I feel Stripes solves that problem, I'll recommend it.

As I have been recommending Stripes for several issues related to JSF, I've found myself comparing the two frameworks in my mind more than on paper and that is what I intend to do here. Obviously this will be a bit biased since JSF lost its luster for me a long time ago, but I'll try to be as fair as I can be. If I state anything that is utterly untrue about JSF or Stripes, I invite anyone to correct me.

I'll spare the history of JSF and Stripes for now. I'll assume you can do your own homework if you want to know when and where both got started. And I am going to jump right into some content. The first thing I would like to do is look at the library requirements for both frameworks. I've left out anything that is optional such as commons-fileupload.jar as well as only including the bare minimum to get simple pages displaying. No Spring, Hibernate, iBatis, or anything like that.

(Note: I am going to be assuming MyFaces as the JSF implementation of choice. If I had to develop a JSF application today, I would choose MyFaces.)

JSF

• commons-beanutils.jar
• commons-codec.jar
• commons-collection.jar
• commons-digester.jar
• commons-lang.jar
• commons-logging.jar
• commons-validator.jar
• tomahawk.1.x.x.jar
• myfaces-impl.jar
• myfaces-api.jar

Stripes

• commons-logging.jar
• cos.jar
• stripes.jar

I don't think any explanation of the above dependencies is necessary. Obviously including JAR files in a web application isn't a big deal nor is it a defining factor in which framework to choose, but interesting none-the-less.

Interestingly Stripes ActionBeans and JSF Backing Beans are quite similar. It's interesting because Stripes is an action based framework (ie: Struts, WebWork, etc) where JSF is considered a component oriented framework (ie: Tapestry, Wicket, etc). There are several differences between the Stripes ActionBean and the JSF Backing Bean which I'll cover as we come to them. Let's begin with a very simple page, but not quite as simple as Hello World. Let's consider a User Registration page. There will be 2 buttons; Submit and Cancel. Submit will save the page and Cancel will simply reset the form fields.

(Note: I don't plan on this being a tutorial or how-to for either framework so you'll notice quite a bit of missing information and code. I will only show enough for a fair comparison. There are tons of JSF tutorials and the Stripes documentation is superb. I'll have links to all this at the end of this article)

Let's begin with the server side code. In the case of JSF, it would be the Backing Bean.

Nothing too fancy here. I assume a User object that contains things like username, password, firstname, lastname, etc. I also realize that as the Backing Bean gets more complex many commonly used methods might be refactored into a Base class that all Backing Beans extend. JSF uses string messages to determine page flow and those messages are duplicated in the faces-config.xml file. Now lets look at the Stripes ActionBean for the same code.

Initially, the JSF server side code is a lot cleaner, shorter, and simpler. As far as lines of code, it is. The difference is that much of the code you see in the Stripes server side code is scattered across a couple of places for JSF. For example, all the validation for simple form fields will be specified in the JSP and the page flow or navigation is in the faces-config.xml. Stripes has no external configuration for such things. It's all encapsulated in one place. This is largely due to annotations.

(Note: Stripes relies heavily on features of Java5. Using Retrotranslator you can get Stripes to work with Java 1.4 since Java5's enhancements are just syntax sugar and the bytecode is pretty much the same. JSF, however, runs just fine on 1.4 without any extra work, at least until the next JSF spec comes out.)

Let's move on to the JSP files. I'll be leaving out much of the HTML required code as well as the TAGLIB requirements for each framework. Both JSF and Stripes use custom tags to help render the page. So they both need these inclusions. Let's begin with Stripes this time.

<stripes:errrors />
<stripes:form action="/Registration.action">
<table>
    <tr>
       <td><stripes:label class="commonLabel" for="user.username">Username</stripes:label></td>
       <td><stripes:text class="commonText" name="user.username" id="user.username" /></td>
    </tr>
    <tr>
       <td><stripes:label for="user.password">Password</stripes:label></td>
       <td><stripes:password name="user.password" id="user.password" /></td>
    </tr>
    <tr>
       <td><stripes:label for="user.firstName">First Name</stripes:label></td>
       <td><stripes:text name="user.firstName" id="user.firstName" /></td>
    </tr>
    <tr>
       <td><stripes:label for="user.lastName">Last Name</stripes:label></td>
       <td><stripes:text name="user.lastName" id="user.lastName" /></td>
    </tr>
    <tr>
       <td><stripes:submit name="register" value="Register" /></td>
       <td><stripes:submit name="cancel" value="Cancel" /></td>
    </tr>
</table>

This requires a bit of explination. First, the form action. Notice that we named our ActionBean RegistrationActionBean. When a stripes web application starts up, Stripes inspects all the classes in the classpath and looks for implementations of ActionBean. It then strips off any package name up to and including the name action and removes ActionBean from the class name. Therefore, the action automagically becomes Registration.action. The .action is mapped in the web.xml via the StripesFilter. The stripes:label is used to look up text from a resource bundle much the same way that JSF does. Notice I only placed a class="" on username field and label. I did this to prove a point in that notice how Stripes uses the same attribute names as standard HTML. You'll see the difference when I show the JSF version. The stripes form tags use the name attribute to map values back to the domain model. In our case, User. This is also how Stripes will redisplay the data in the case of a validation errors and general model persistence to and from the server. Basic MVC stuff here. Stripes also uses the name attribute for submit buttons to map them to methods in the ActionBean. So when you click the Register button, the register method is called. This is also quite similar to JSF, which I'll move to now.

<f:view>
    <t:messages />
       <h:form >
          <h:panelGrid columns="2">
             <h:outputLabel styleClass="commonLabel" for="username" value="#{messages.email}" />
             <h:inputText styleClass="commonText" id="username" value="#{registrationForm.user.username}" required="true" />
             <h:outputLabel for="password" value="#{messages.password}" />
             <h:inputSecret id="password" value="#{registrationForm.user.password}" required="true" />
             <h:outputLabel id="firstName" value="#{messages.firstName}" />
             <h:inputText id="firstName" value="#{registrationForm.user.firstName}" required="true" />
             <h:outputLabel id="lastName" value="#{messages.lastName}" />
             <h:inputText id="lastName" value="#{registrationForm.user.lastName}" required="true" />
             <h:commandButton id="registrationButton" value="#{messages.registrationButton}" action="${registrationForm.register}" />
             <h:commandButton id="cancelButton" value="#{messages.cancelButton}" action="#{registrationForm.cancel}" immediate="true" />
          </h:panelGroup>
       </h:form>
</f:view>

JSF requires all pages to be placed in a "view" for the component tree. General and validation messages are displayed pretty much the same way through a tag. JSF has tags to spit out HTML components. For example, the panelGrid will create a table. Currently, JSF requires tags to be enclosed in tags. If I were to simply use a TABLE as I did in the Stripes example, the component tree could become disordered and your JSF components might render in unexpected places. I believe this is going to be fixed in the next JSF release (1.2) and hopefully someone can confirm this. Notice also that instead of simply using the word class, JSF changes it to styleClass. Struts also does this. But it's weird. JSF uses EL syntax for pulling values out of the backing bean as well as from the resource bundle. Notice that in JSF we use the # rather than $. I believe that the next JSP spec is more in line with JSF style EL so that the 2 work together better.

I'd challenge you to change the extension of these files to .html and open both in a web browser on your local machine. Looking at this from a designer's POV, I know which one I'd rather work with.

The good news is that aside from the web.xml the Stripes code is complete. The bad news is that for JSF, we still need another file. We need the faces-config.xml which loads the backing beans and configures the page flow or navigation.

<managed-bean>
    <managed-bean-name>registrationForm</managed-bean-name>
    <managed-bean-class>com.test.beans.RegistrationBean</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

<navigation-rule>
    <from-view-id>/register.jsp</from-view-id>
    <navigation-case>
       <from-outcome>success</from-outcome>
       <to-view-id>welcome.jsp</to-view-id>
       <redirect />
    </navigation-case>
    <navigation-case>
       <from-outcome>failure</from-outcome>
       <to-view-id>register.jsp</to-view-id>
    </navigation-case>
</navigation-rule>

Nothing too fancy or complicated there so I won't go into much detail. Even if you have never used JSF, it's pretty easy to determine what is going on.

Up to this point the frameworks don't seem that different. Both use a Java Bean of sorts for the backing code. Both use custom tags for forms. Both have a solid validation engine. Beyond that, and internally, there are significant differences. And I can't very well go into them in detail without really showing my bias towards Stripes. With this article, I just wanted to show everyone a bit of each and let you start making your own conclusions which will be easier for you as you develop with each framework.

Depending on the response to this article, I may write another one that is geared more at where I believe Stripes is superior to JSF. I just didn't feel like getting all the hate mail this morning.

Resources:

• http://stripes.mc4j.org/confluence/display/stripes/Home
• http://myfaces.apache.org/
• http://java.sun.com/javaee/javaserverfaces/
• http://www.jsftutorials.net/