JSF is a UI component framework for J2EE applications. You can invest a lot of time into the application to make it rich and interactive using various technologies but how do you maintain such an application? How do you reuse what you have built?
JSF is all about components!
Component Model
JSF simplifys life for application developers, making it possible for them to focus on the view without needing to know the
underlying markup or scripts.
The goal is to provide an easy way to construct UIs from a set of reusable UI components.
These reusable components come in various shapes with different functionality, from layout components (such as the layout of an entire page) to simple buttons. Application developers can use these components to construct a page and nest UI components within each other to get the desired effect. This structure of nested components is often referred to as a parent-to-child relationship and visualized as a UI component hierarchy. This UI component hierarchy represents a JSF page description at runtime.
Navigation Model
JSF provides a declarative navigation model.
Navigation rules in JSF are defined inside the JSF configuration file, faces-config.xml, and are page-based.
Navigation rules are based on outcomes which are the return values from actions performed in the application such as a button being clicked. In JSF, an action is attached to the UIComponent, which allows for fine-grained control on the page. These actions can either have their own navigation rule or share the same navigation rule.
Application Lifecycle
Another benefit when using JSF is that the framework helps manage UI state across server requests. Instead of having to take care of user selections and passing these selections from page to page, the framework will handle this for you.
The JSF framework also has built-in processes in the lifecycle to assist with validation, conversion, and model updates.
JSF Architecture
JSF implements what is known as the Model 2 pattern, which is based on the MVC architecture.
The JSF architecture is designed to be independent of specific protocols and markup, and allows developers to attach any rendering technology to the JSF application.
In JSF it is the RenderKit that is responsible for the presentation of the JSF application and you can define a RenderKit for any type of markup (HTML, WML, Telnet).
This separation between the page description (UI component hierarchy) and the rendering of markup is a key differentiator that provides flexibility to the component developer while protecting the application developer from changes isolated at the rendering layer.
Model
With JSF, the concept of a managed bean has been introduced which is the interface to the application logic—backing code.
Managed beans are defined in the faces-config.xml file and give the application developer full access to all the mapped backing bean’s methods.
In JSF, a backing bean is a plain old Java object (POJO) with no dependency on implementation-specific interfaces or classes. The JSF controller—the FacesServlet—is not aware of what action has been taken; it is aware only of the outcome of a particular action and will use that outcome to decide where to navigate.
In JSF it is the component that is aware of which action, or method, to call on a particular user event.
View
The JSF view layer describes the intended layout, behavior, and rendering of the application. A developer would use these UIComponents to construct an application by nesting components within each other. This nested structure will at runtime be represented as a component hierarchy.
The default page description defined by the JSF specification is JSP, but there is nothing in the JSF specification preventing an implementer from providing an alternative page description.
Controller
JSF comes with a simple controller—the FacesServlet. The FacesServlet acts as a gatekeeper,
controlling navigation flow and dispatching requests to the appropriate JSF page.