JSF - Java Server Faces Tutorials
JavaServer(TM) Faces technology simplifies building user interfaces for JavaServer applications. Developers of various skill levels can quickly build web applications by: assembling reusable UI components in a page; connecting these components to an application data source; and wiring client-generated events to server-side event handlers.Developed through the Java Community Process under JSR - 314, JavaServer Faces technology establishes the standard for building server-side user interfaces. With the contributions of the expert group, the JavaServer Faces APIs are being designed so that they can be leveraged by tools that will make web application development even easier. Several respected tools vendors were members of the JSR-314 expert group, which developed the JavaServer Faces 1.0 specification. These vendors are committed to supporting the JavaServer Faces technology in their tools, thus promoting the adoption of the JavaServer Faces technology standard.
Core features
- Managed Beans: A dependency injection system (easily interfaced with CDI, Spring, or Guice) - also called "Backing Beans" or "Page Beans"
- A template-based component system, for rapid composite component creation - without the need for Java classes.
- Built in Ajax support using <f:ajax /> (since JSF v2.0).
- Built in support for bookmarking & page-load actions.
- Integration with the Unified Expression Language (EL), which is core to the function of JSF. Views may access managed bean fields and methods via EL: <my:component rendered="#{myBean.userLoggedIn}" />
- A default set of HTML and web-application specific UI components
- A server-side event model : For dispatching events and attaching listeners to core system functionality, such as "Before Render Response" or "After Validation"
- State management, supporting: "request", "session", "application", "flash", and "view" scoped Java beans.
- Two XML-based tag libraries (core and html) for expressing a JavaServer Faces interface within a view template (can be used with both JSP or Facelets)
JSF versions
- JSF 2.1 (2010-10-22) — Current version. Second maintenance release of 2.0. Only very minor amount of spec changes
- JSF 2.0 (2009-06-28) — Major release for ease of use, enhanced functionality, and performance. Coincides with Java EE 6.
- JSF 1.2 (2006-05-11) — Many improvements to core systems and APIs. Coincides with Java EE 5. Initial adoption into Java EE.
- JSF 1.1 (2004-05-27) — (DEPRECATED) bug fix release. There were no spec or HTML renderkit changes.
- JSF 1.0 (2004-03-11) — (DEPRECATED) the initial release of the JSF specification. Separate release that wasn't part of any Java EE/J2EE release.
JSF Life Cycle
In this we will understand the life cycle of JSF application.
Life cycle of a JSF web application starts when user makes a request. On submission of a page various further tasks are performed like validation of data provided in components in the view, data conversion according to types specified on server side etc. So series of steps that an application follows is called life cycle.
A JSF application typically follows six steps in its life :
1. Restore view phase :
This phase starts when a user requests a JSF page by clicking a link, button etc. In this phase view generation of the page, binding of components to its event handlers and validators are performed and view is saved in the FacesContext object. The FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session. The FacesContext stores the view in its viewRoot property.All the JSF components are contained by viewRoot for the current view ID. Component tree of a page is newly built or restored.
A request comes through the FacesServlet controller. The controller checks the request and takes the view ID i.e. name of the JSP page. View ID is used to look up the components in the current view. JSF controller uses this ID if the view already exists . If the view doesn't already exist, the JSF controller creates it. The created view contains all components.
This phase starts when a user requests a JSF page by clicking a link, button etc. In this phase view generation of the page, binding of components to its event handlers and validators are performed and view is saved in the FacesContext object. The FacesContext object contains all the state information JSF needs to manage the GUI component's state for the current request in the current session. The FacesContext stores the view in its viewRoot property.All the JSF components are contained by viewRoot for the current view ID. Component tree of a page is newly built or restored.
A request comes through the FacesServlet controller. The controller checks the request and takes the view ID i.e. name of the JSP page. View ID is used to look up the components in the current view. JSF controller uses this ID if the view already exists . If the view doesn't already exist, the JSF controller creates it. The created view contains all components.
2. Apply request values phase :
The purpose of this phase is for each component to retrieve its current state. After restoring of component tree in previous phase each component in the tree retrieves its new value and store it locally. Component values are typically retrieved from the request parameters.If immediate attribute of a component is set to true, then the validation, conversion, and events associated with the component is processed in this phase.
If a component's immediate event handling property is not set to true, the values are converted. Suppose field is bound to be an Integer property, the value is converted to an Integer. An error message associated with the component is generated if this conversion fails, and queued in the FacesContext. This message will be displayed during the render response phase, along with any validation errors resulting from next process validation phase.
At the end of this phase, the components are set to their new values, and messages and events have been queued.
The purpose of this phase is for each component to retrieve its current state. After restoring of component tree in previous phase each component in the tree retrieves its new value and store it locally. Component values are typically retrieved from the request parameters.If immediate attribute of a component is set to true, then the validation, conversion, and events associated with the component is processed in this phase.
If a component's immediate event handling property is not set to true, the values are converted. Suppose field is bound to be an Integer property, the value is converted to an Integer. An error message associated with the component is generated if this conversion fails, and queued in the FacesContext. This message will be displayed during the render response phase, along with any validation errors resulting from next process validation phase.
At the end of this phase, the components are set to their new values, and messages and events have been queued.
3. Process validations phase :
During this phase local values stored for the component in the tree are compared to the validation rules registered for the components. If local value is invalid, an error message is added to FacesContext, and the component is treated invalid then JSF proceeds to the render response phase and display the current view showing the validation error messages. If there were conversion errors from the apply request values phase, the messages for these errors are also displayed. If there are no validation errors, JSF proceeds ahead to the update model values phase.
During this phase local values stored for the component in the tree are compared to the validation rules registered for the components. If local value is invalid, an error message is added to FacesContext, and the component is treated invalid then JSF proceeds to the render response phase and display the current view showing the validation error messages. If there were conversion errors from the apply request values phase, the messages for these errors are also displayed. If there are no validation errors, JSF proceeds ahead to the update model values phase.
4. Update model values phase :
After confirming that data is valid in the previous phase local values of components can be set to corresponding server side object properties i.e. backing beans. So bean properties will be updated .If the local data cannot be converted to the types specified by the bean properties, the life cycle proceeds directly to the render response phase and errors are displayed.
After confirming that data is valid in the previous phase local values of components can be set to corresponding server side object properties i.e. backing beans. So bean properties will be updated .If the local data cannot be converted to the types specified by the bean properties, the life cycle proceeds directly to the render response phase and errors are displayed.
5. Invoke application phase :
Before this phase the component values have been converted, validated, and applied to the bean objects, so you can now use them to execute the application's business logic. Application-level code is executed such as submitting a form or linking to another page.For example user moves to the next page you will have to create a mapping in the faces-config.xml file. Once this navigation occurs, you move to the final phase of the lifecycle.
Before this phase the component values have been converted, validated, and applied to the bean objects, so you can now use them to execute the application's business logic. Application-level code is executed such as submitting a form or linking to another page.For example user moves to the next page you will have to create a mapping in the faces-config.xml file. Once this navigation occurs, you move to the final phase of the lifecycle.
6. Render response phase:
In this phase JSP container renders the page back to the user,if jsp is used by application i.e. view is displayed with all of its components in their current state.If this is an initial request, the components will be added to the component tree. If this is not an initial request, the components are not added because they are already added to the tree.The state of the response is saved after rendering of the content of the view, so that subsequent requests can access it and it is available to the restore view phase.
In this phase JSP container renders the page back to the user,if jsp is used by application i.e. view is displayed with all of its components in their current state.If this is an initial request, the components will be added to the component tree. If this is not an initial request, the components are not added because they are already added to the tree.The state of the response is saved after rendering of the content of the view, so that subsequent requests can access it and it is available to the restore view phase.
- JavaServer Faces technology is a framework for building user interfaces for web applications. JavaServer Faces technology includes:
- Java APIs to represent UI components, manage state, handle events, and validate input. The API has support for internationalization and accessibility.
- Two JSP custom tag libraries for expressing user interface (UI) components within a JSP page, and for wiring components to server-side objects. Page authors can easily add UI components to their pages.
- JavaServer Faces technology is based on the Model View Controller (MVC) architecture for separating logic from presentation, so if you have been practicing this, you'll feel at home with JSF
- A JSF application is just like any other Java technology-based web application; it runs in a Java servlet container, and contains:
- JavaBeans components (or model objects) containing application-specific functionality and data
-- Event listeners -- JSP pages
-- Server-side helper classes
-- A custom tag library for rendering UI components
-- A custom tag library for representing event handlers and validators
-- UI components represented as stateful objects on the server
-- Validators, event handlers, and navigation handlers.
-- Application configuration resource file for configuring application resources - One of the advantages of JSF is that it is based on the Model View Controller (MVC) architecture, to offer a clean separation between presentation and logic. This may ring a bell for those who are using existing web frameworks such as Struts. However, note that JSF and Struts are not competing technologies, and in fact, they interoperate together. JSF, however, does have some advantages over Struts. For example, in Struts there is only one way to render an element, while JSF provides several mechanisms for rendering an individual element. It is up to the page designer to pick the desired representation, and the application developer doesn't need to know which mechanism was used to render a component
The author of Struts, Craig McClanahan, is also the co-specification lead for JSF, as well as an employee of Sun Microsystems.
The primary benefits of JavaServer Faces technology include:
- Ease-of-Use: Several aspects of the JavaServer Faces architecture contribute to its ease-of-use. For one, JavaServer Faces technology offers a clean separation between logic and presentation, enabling a wide range of users -- from web-page designers to component developers-- to take advantage of JavaServer technology, resulting in a division of labor and a shorter development cycle. Also, a user-interface created with JavaServer Faces technology handles all the complexities of user-interface management, including input validation, component-state management, page navigation, and event handling.
- Standardization: JavaServer Faces technology is being developed through the Java Community Process. Several prominent, respected tools vendors are contributing members of the expert group and are committed to supporting JavaServer Faces technology in their tools.
- Device Independence: JavaServer Faces technology is designed to be flexible. By defining only component functionality in extensible UI component classes, the JavaServer Faces architecture allows component developers to extend the component classes to generate their own component tag libraries targetted for specific clients.
No comments:
Post a Comment