The Right Portal Framework

Consideration:

For any j2ee framework there are three well established industry recognized framework exists. Struts, JSF and Spring.

So which one is right when we go with Portal technology. Let’s compare apples and oranges.


Does Struts Satisfy Needs?

Struts1.x

Pros:

• Struts have been around for a few years and have the edge on maturity. And since it here from many years there are many developers who know struts very well.

Cons:

• It is one of the first MVC framework, and hence very cumbersome and "backward" by today's standards (because of the need to maintain backward compatibility, they can't rearchitect it the way it should be done).
  
• The heart of Struts is the Controller. Struts use the Front Controller Pattern and Command Pattern. A single servlet takes a request, translates HTTP parameters into a Java ActionForm, and passes the ActionForm into a Struts Action class, which is a command. The URI denotes which Action class to go to. The Struts framework has one single event handler for the HTTP request. Once the request is met, the Action returns the result back to the front controller, which then uses it to choose where to navigate next. This structure restricts struts to handle only one event per request.
  
• Struts were designed to be model neutral, so there are no special hooks into a model layer. There are a view reflection-based copy utilities, but that's it. Usually, page data must be moved from an Action Form into another Model input format and requires manual coding. The Action Form class provides an extra layer of tedious coding and state transition.

Struts2.x

• Struts1.x+webwork2 = Struts2.x
  
• It provides some goodies like:
  -Stateful Checkboxes
  -First class AJAX support
  -Easy integration with Spring Framework
  -No More Actions Forms, use POJO forms
  -Easy to Customize Controller
  -Easy Plugins etc. etc.
  
• The major change in Struts 2 might be learning curve for developers.

Does JSF Satisfy Needs?

Pros:

• JSF is an official standard from sun. It is a Specification, hence will have lots of implementations. It is also now part of the J2EE specs. Therefore any vendor that wants to be J2EE compliant is forced to come out with a JSF implementation and provide support for it.
  
• JSF has been designed from the ground up to support Portlets (JSR 168). It just fits into the portal. It is almost like a container agnostic framework. You can write JSF for standard web development and then turn around and put it into a portlet with little if any change.
  
• JSF was built with a component model in mind to allow tool developers to support RAD development. JSF provides the ability to build components from variety of view technologies like Rational Software Developer etc.
  
• JSF uses the Page Controller Pattern. Although there is a single servlet every faces request goes through, the job of the servlet is to receive a faces page with components. It will then fire off events for each component and render the components using a render toolkit. The components can also be bound to data from the model. Thus JSF can have several event handlers on a page and can be hooked into model without breaking model, In short, JSF adds many benefits of FrontController but at the same time gives flexibility of Page Controller.
  
• The new portlet specification JSR286 as opposed to JSR -168, speaks quite a bit on the topic of JSF support. It's just an added bit of confidence that the JSF portlet apps we write now will be very portable in future portal applications servers.
  
• IBM is a pioneer in portlet technology and although they heavily supported struts in their portal, their portal team strongly recommends using JSF instead of struts.

Cons:

• Using JSTL in JSF produces un-specified results. It does not work some times.
  
• There is no apparent support for Portlet Modes or Preferences.

Does Spring Satisfy Needs?

• Spring itself is more than a MVC framework. Spring is made up of many components, main component being the Core Container (Beans, BeanFactory, ApplicationContext, etc) that provide the Dependency injection via a lightweight container, and the rest of the components (e.g. AOP, Transaction Management, etc. ) are built around it.
  
• The idea is that Spring allows you to use what ever you want, to mix and match its components easily. So in effect, you can use Spring to do your Transaction Management and AOP but choose to use Spring MVC, Struts or JSF as your MVC framework.
  
• Spring MVC is again action oriented framework like Struts and unlike JSF and Tapestry.
  
• There is a Spring Portlet Framework available now, which is gaining industry acceptance.

Can we think of Tapestry?

• Tapestry is innovative, and since it is complicated to use. It has a steep learning curve.
  
• JSF and Tapestry have fundamental similarities, but here is a very good discussion of using one over another.

Conclusion:

1. In general, unless there is a compelling need, direct use of portlet API is recommended instead of using any framework. For less complicated portlets can also give a thought of using tools like IBM portlet factory.
   
2. As till today there is no specific portlet framework available, till then a long-term strategy would be to move to JSF as other then all the pros following information also forces to use JSF.
   -JSF has Specification.
   -It is integrated in JEE 5
   
3. At first glance Struts 2 looks promising, but yet not proved as being very new and developers are readily not available.