This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
I have been reading few articles, on struts and JSF. I have found at many places that JSF is the better way to build UI using components. Can someone please tell how these components helps in building better UI's. How it is better then struts ?
The set of UI components supplied with JSF is extensible - indeed, the extensions will no doubt outstrip the supplied components in short order, by extending and combining them into more sophisticated UI elements. Tool developers can now create UI-paint applications that manipulate JSF components, as opposed to framework-specific elements (such as tags or XSL elements), allowing the page designer to say "place one of this type of component here, bind it to the following property in the application". JSF components are associated with a value from the underlying application logic, and may also be associated with one or more "events" that are triggered when the component is manipulated by the user. These events (the equivalent of a "submit" operation in Servlet terms) trigger a chain of processing called the JSF life cycle. In brief, this life cycle applies the request parameters to the "tree" of non-visual components (creating one, if necessary), performs necessary validations and type conversions, then passes the values to the application logic and triggers the method associated with the event. This life cycle can be abbreviated by, for example, validation errors, causing the page to be re-displayed with all of the values intact (in addition, likely, to an error message telling the user why the validation failed). This avoids calling the application logic entirely, at least for simple validations. Assuming the validations and conversions were successful, the application did get called, the "tree" of components associated with this request is cached for later use, and the application goes on to the next logical step. Some events will return to the same logical page, so the ability to cache the page of components and their associated values allows the page to be modified and then re-displayed: for example, filling in a customer code might result in the customer name being displayed alongside it, while the remainder of the page remains the same. This kind of "state saving" helps build web-based applications that provide a more "traditional" UI experience for the user, while not imposing an additional burden on the application logic.