Some notes for JSF

The three points that we discussed were:

1. Mutliple render kits:

Now a days there are many devices that are web enabled. So application developers have challenge to develop components that can work across various platforms. For example, if we have an application that works on standard web browser and we want to extend it to make it enable to work on a WAP device. So, to handle this case we need components to be rendered in more than one way. Here JSF can help you . It is a simple task for JSF. Solution is to develop separate renderers for the component. JSF components use different renderers depending on the device used.

Render kit can target a specific device like phone, PC or markup language like HTML,WML, SVG. This is one of the best benefit of JSF because JSF doesn't limit to any device or markup.

2. Controller Flexibility/Event Handling

JSF is a component/event oriented approach, and Struts is an action oriented approach.

One of the major goals of Struts was to implement a framework that utilized Sun's Model 2 framework and reduced the common and often repetitive tasks in Servlet and JSP development. The heart of Struts is the Controller. Struts uses 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.
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. JSF is the winner in this area, because it adds many benefits of a front controller, but at the same time gives you the flexibility of the Page Controller.

JSF can have several event handlers on a page while Struts is geared to one event per request. In addition, with Struts, your ActionForms have to extend Struts classes, creating another layer of tedious coding or bad design by forcing your model to be ActionForms. JSF, on the other hand, gives developers the ability to hook into the model without breaking layering.

3. JSF Component Tree
The user interface can be by nature hierarchical, and we can structure the code to reflect that. For very dynamic parts of the user interface, programmatic manipulation is useful. But, this is certainly the uncommon case. Most user interfaces are extremely static except at the level of individual controls. JSF helps you even in this uncommon case, since it lets you directly manipulate the JSF component tree in Java code. And of course, you can always fall back to writing JavaScript code that works with the browser's DOM.

Message from my java group...it would be much helpful in understanding on this topic

Struts a bit excessive and using it was like trying to fit a square peg in a round hole.

In Struts 1.x, you can only have String objects in ActionForms. Whereas, in JSF, you
can even have Date, BigDecimal, Integer, etc. in the ManagedBeans.

The JSF ManagedBeans are a combination of Struts ActionForm and Action both rolled into one. Again, in Struts Action, only the execute method is ever exposed. Whereas, in JSF, you can have any method being called by the front-end.

But thats not all. Validation is a big pain in Struts. It is tucked away in validation.xml or in some cases, in ActionForm or Action. Whereas, in JSF, you can have validation and conversion at front-end.

With all this going on, you might think that this is the best solution.

However, the trouble here is you still have the attributes being duplicated in your ManagedBeans and again in the Entities that you will persist.

For example, if you have a users table, you will end up having a Java Class Users for storing database entity and a Java Class UsersBean to use as your ManagedBean. And then just like the Struts days, where you write code to take ActionForm values and store them to the Entity before saving to database and vice versa when reading them from database, you will do same conversion from ManagedBean to Entity and
back in JSF.

In brief, the comparison as as follows:

Struts:

1. JSP with Struts tags
2. Configuration in struts-config. xml
3. Flow controlled by ActionServlet
4. Validation in validation.xml
5. Available for free
6. Only Apache implementation
7. No components available

JSF:

1. JSP with JSF tags
2. Configuration in faces-config. xml
3. Flow controlled by FacesServlet
4. Validation in the front-end
5. Available for free
6. Implementations - Apache MyFaces, Sun Reference Implementation
(recommended one for now)
7. Components available from RichFaces, IceFaces, AJAX4JSF and many
more

Now, just a small introduction to what Seam does here.

With JSF or Struts, you need beans on the front-end (ManagedBean or ActionForm) to hold front-end values and beans on the back-end to hold back-end values. And then you have to write plumbing code to transfer values back and forward between front-end and back-end beans.

Seam collapses the need for all this and allows you to expose entities directly onto the front-end.

It also makes use of Hibernate Annotations such as not-null for required fields and length to check for max-length of input fields.

If you are interested, I can post an article on a brief introduction to Seam and getting started with it. Must warn you a bit though that you do need about a month or so to get to grips with Seam like any other application such as Struts, Spring or Hibernate.