Developing Web Interfaces with JSF (Continued)

JSF Application Components
J2EE Web application developers will find JSF applications straightforward and easy to understand. A JSF application is essentially a standard J2EE application with a set of required components:

• Faces servlet configured in web.xml – The faces servlet acts as a Model-View-Controller controller or a traffic cop for all requests to Web application elements. Jakarta Struts developers will find this component almost identical to the Struts controller servlet.
  
• A faces configuration file – The JSF configuration file, faces-config.xml, is also similar to the Struts configuration file by serving as a master configuration file for the application's components and navigation model.
  
• Required JAR files – Every JSF application will need these JAR files in the application's WEB-INF/lib directory: jsf-api.jar, jsf-ri.jar, jstl.jar, standard.jar, commons-beanutils.jar, commons-digester.jar, commons-collections.jar, and commons-logging.jar.

Typically, a JSF application consists of the required components, managed model Java beans, as well as JSP and HTML files to present the UI. Incidentally, JSF application UIs can also be constructed entirely from well-formed XML documents rather than JSP pages. For deployment, JSF applications do not require a specially configured run-time environment, but can be deployed standalone to any standard J2EE container such as Tomcat. The JSF API provides developers with this set of tools: a rich library of UI components for productive application assembly that range from simple text labeling or input tags to more complex components; a JSF core tag library that handles events and performs validations and other non-UI-related actions; and a standard HTML renderer kit tag library for rendering UI components in JSPs.

The typical JSF application development scenario involves configuring a J2EE Web application with the required JSF components. A Web page designer designs the overall application in a series of JSP/HTML pages that are initially just static designs. Component developers have the option of building custom UI components and/or new renderers of existing JSF UI components. For example, custom renderers could be built for non-HTML-based clients such as Wireless Markup Language or other client technologies. Finally, Web application developers then assemble a complete JSF application using the static HTML design, the provided JSF tag libraries along with any custom components, and data management or model beans.

Now let's see how a JSF application works at runtime—the JSF life-cycle process. This process is similar to the life cycles of most Web applications in that a Web client makes an HTTP request, the application receives and processes the request, and then replies in HTML. However, the JSF life cycle is more involved because it manages a run-time View or UI component tree that is a managed server-side, run-time representation of the UI. This life cycle allows JSF applications more flexibility in handling state changes and controlling events. Additionally, runtime for a JSF application must manage different HTTP requests in different ways depending on whether the requests come from inside or outside of the JSF application.