Misra’s blog

JSF vs Struts

Posted by mtwinkle on July 10, 2007


#10: There’s only one Struts

Struts is an open-source product, whereas JSF is a specification.

#9: JSF is the standard

JEE 5.0 containers must provide an implementation of JSF, which means that JSF will soon be ubiquitous.#8: POJO Action Methods

Struts actions are tied to the Struts API, but JSF action methods can be implemented in Plain Old Java Objects.
#7: Managed Beans

Like Spring, JSF uses dependency injection (or inversion of control, if you will), for instantiating and initializing beans. It’s true that Struts creates action beans and form beans for you, but JSF generalizes that concept and adds the ability to initialize managed beans—of any type—created by the framework.#6: Extensibility

This is huge. JSF has 6 objects that implement much of the framework’s capabilities and you can easily replace those objects by decorating the default implementations. That makes it ridiculously easy, for example, to add your own custom variables to the JSF expression language. It also makes it easy, for example, to plug in your own view handlers, perhaps a view handler that implements Tapestry-like views so you can truly separate components and HTML. In fact, Shale, does both of those things. As if that weren’t enough, JSF gives you numerous hooks into the JSF lifecycle to inject your own voodoo. Shale gives you even more.#5: Event Model

JSF has an event model that lets you react to value changes, actions, and phase changes in the JSF lifecycle.
#4: Value Bindings

With Struts, you are responsible for ferrying data from your forms to your model objects. You implement an action with an execute method that takes a form bean as an argument. Then you manually pull data out of that form bean and push it to your model. For every form in your application. Ugh. With JSF, you do this: #{model.property}. That’s all. JSF takes care of the rest.#3: Renderers

Have you ever looked at the source code for Struts tags? They generate HTML directly. JSF component tags, OTOH, don’t generate anything; instead, they refer to a component-renderer pair on the server. The component maintains state whereas the renderer is in charge of rendering a view. The point here is that renderers are pluggable: you can replace the default renderers with your own implementations; for example, in my Felix talk at NFJS, I illustrate how to implement a custom label renderer that adds asteriks to labels that represent required fields. You plug in that renderer, and JSF will automatically use it throughout your application. Sweet.#2: Render Kits

I had a Struts consulting job a few years ago where we had to support both a browser-based interface and radio frequency devices, and it was painful. That task would’ve been greatly simplified with JSF because you can create your own render kit—a collection of renderers for a particular display technology—and plug it into JSF.#1: Components

Components are the number one differentiator between Struts and JSF. Like Swing, JSF provides a rich infrastructure for developing components in addition to a standard set of components. That infrastructure makes it relatively easy to create your own components and share them with others. Already, we’re seeing custom components popping up all over the place, for example with Oracle’s ADF and MyFaces, both of which provide a rich set of components such as JavaScript-powered calendars, trees, etc. Of course, components are only half the story; typically, components delegate rendering to a separate renderer, which provides substantial benefits (see item #3 above). But, as with most things in JSF, you are not forced to adhere to the party line. If you want, you can implement components that render themselves, although if you do so, you will loose the ability to plug a different renderer into your component.


3 Responses to “JSF vs Struts”

  1. I would have to say, the most common question or feedback came along the lines of comparing Struts to JSF. I thought it would be a good idea to compare JSF to Struts by evaluating various features that an application architect would look for in a Web application framework. This article will compare specific features. Those on which I will focus include:

    * Maturity
    * Controller Flexibility/Event Handling
    * Navigation
    * Page development
    * Integration
    * Extensibility

    Certainly, there are other places in which you might want to do a comparison, such as performance, but I’ll focus on the set I just mentioned. I’ll also spend more time on the Controller and Navigation sections because they are the heart of the frameworks. Performance of JSF is specific to the vendor implementation, and I always encourage people to perform their own performance tests against their own set of requirements because there are too many factors that can affect performance. A performance evaluation would be unfair. Other areas such as page layout, validation, and exception handling were also left out in the interest of saving space.

  2. Saabir said

    A very nice article .
    “had a Struts consulting job a few years ago where we had to support both a browser-based interface and radio frequency devices”. really interests me.
    I am currently working on an accessiblieWebsite and I was thinking should I implement a customRendererKit for certainPages(searchResultPages=tree/dataGrid) or simply solve this facelets?
    What do u think?


  3. But wanna say that this really is quite valuable , Thanks for taking your time to write this. 775270

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: