Monday, October 11, 2010

Difference between Struts and JSF

Struts is an Action framework and JSF is component framework.
Action Framework: Struts (both 1 and 2) are action frameworks. In essence they give you the ability to map URLs to activities and code on the back end. Here, the layout and workflow tends to be more page oriented. As a developer you tend to interact with the HTTP request cycle directly, though Struts 2 helps isolate at least the binding of the request data to the action implementation classes.
Action framework coders can have more control of the structure and presentation of URLs, since their systems are more intimately tied to them compared to a component framework.
Component Framework: In a component framework, artifacts that are rendered on the page are initially developed as individual components, much like in modern GUI "fat client" libraries. You have components, they have events, and your code is written to work with those events against the components. Most of the time, in mainstream development, your code is pretty much ignorant of the HTTP request cycle and processing.
JSF eliminated the need of Form Bean and DTO classes as it allows the use of same pojo class on all tiers of the application because of the Backing Bean.
In struts framework we can access the request and response objects directly, as in case of JSF we can access request and response objects indirectly.
Struts has a more sophisticated controller architecture than does JavaServer Faces technology. Struts is more sophisticated partly because the application developer can access the controller by creating an Action object that can integrate with the controller, whereas JavaServer Faces technology does not allow access to the controller.
In addition, the Struts controller can do things like access control on each Action based on user roles. This functionality is not provided by JavaServer Faces technology.
Struts frameworks is  better for "web sites", site like this one, sites that focus on delivering content to the user. Where it's mostly a "read only" experience for the end user who is likely to want to bookmark things, come back to arbitrarily deep pages, etc.
JSF framework is better for CRUD screens, back office applications, lots of forms and controls, etc. Here, the workflow is more controlled. You tend to not get to a "detail" screen with going through the "list" screen or "header" screen first, for example.
struts validate full beans (validator.xml) jsf has a pluggable validator-mechanism

Friday, October 1, 2010

Available implementations and Plugins of JSF?


JSF is the java specification given by the sun microsystems. For this specifications there are multiple;e implementations from the different third party vendors. 
The main implementations of JavaServer Faces are:
  1. Reference Implementation (RI) by Sun Micro systems.
  2. Apache MyFaces is an open source JavaServer Faces (JSF) implementation or run-time.
  3. ADF Faces is Oracle’s implementation for the JSF standard.

The main Pluginsof JavaServer Faces are: 
  1. Ice Faces FROM ICEsoft Technologies Inc.
  2. Prime Faces from Prime Technology.
  3. Rich Faces from JBoss
  4. Open Faces from TeamDevLtd
  5. DOJO Faces from DOJO 

Advantages of JSF

The major benefits of JavaServer Faces (JSF) technology are:
  1. JavaServer Faces architecture makes it easy for the developers to use. In JavaServer Faces technology, user interfaces can be created easily with its built-in UI component library, which handles most of the complexities of user interface management. 
  2. Offers a clean separation between behavior and presentation.
  3. Provides a rich architecture for managing component state, processing component data, validating user input, and handling events.
  4. Robust event handling mechanism.
  5. Events easily tied to server-side code.
  6. Render kit support for different clients
  7. Component-level control over statefulness
  8. Highly 'pluggable' - components, view handler, etc
  9. JSF also supports internationalization and accessibility
  10. Offers multiple, standardized vendor implementations