Programming Jakarta Struts, 2nd Edition [Electronic resources] نسخه متنی

18.2 Overview of JSF Architecture

The architecture of JSF is
not completely unlike other MVC architectures you've
probably encountered when building web applications. In fact, some of
its pieces should be quite familiar now that you've
read this book. However, JFS adds functionality in several places
where Struts is lacking, and it does so a way that separates
interface from implementation. As stated earlier, this is an
important (but often overlooked) quality.

Because it's built around the MVC concept, you might
expect to see models, views, and controllers in JSF. And while these
elements are all present in JSF, the web imposes some distinct
limitations on the MVC model. Let's look at a
simplified scenario of how a traditional MVC architecture works:

1. The view responds to user actions by invoking methods on the
   controller.

2. The controller interacts with the model and updates it.

3. The model creates and publishes events that views and controllers
   respond to by updating themselves.

Unfortunately, these steps don't work in the web
world. Web browsers rarely sit and wait for an event to be published.
Instead, they make a request for information and then expect that
information to be returnedthey are certainly not
preconditioned to listen for events.

JSF's approach is to provide components to handle
the controller aspects of the application. These include the
FrontController (similar to the Struts
ActionServlet),
NavigationHandler, conversion and formatting
components, ActionListeners to interpret the
commands, and validate the presentation data. JSF also provides
components for the view. These are implemented as client-specific
rendering kits made up of renderers. These renderers know how to make
items such as a buttons or text fields in a browser.

JSF contains these essential ingredients:

Reusable UI Components

Components for buttons, text fields, and other visual elements.

Renderers

For rendering data to the appropriate client type (e.g. HTML for web
browsers).

Validation and Conversion

Tools to convert and validate client-specific types to Java types
(e.g., user-entered text to a Java Date).

Component Tree

An in-memory representation of the user interface.

18.2.1 The JSF Request/Response Lifecycle

A JSF application supports two types of
requests and two types of responses:

Faces request

A request sent from a previously generated JSF response.

Non-Faces request

A request sent to an application component such as a servlet or JSP.

Faces response

A response created by the rendering response phase of the JSF
processing lifecycle.

Non-Faces response

A response that was not created by the rendering
response phone (e.g., a JSP that doesn't include JSF
components).

According to the specification, these different requests and
responses result in three possible lifecycles for a JSF application:

• Non-Faces request generates a Faces response

• Faces request generates a non-Faces response

• Faces request generates a Faces response (probably the most common)

Figure 18-1 illustrates the request/response
lifecycle for the standard scenario.

Figure 18-1. The standard JSF request/response lifecycle

As mentioned earlier, there are more similarities than differences
between JSF and Struts. The low-level components within JSF sound a
great deal like the components included with the Struts tag
libraries. In fact, there's a great deal of overlap
between these seemingly disparate technologies, and Craig
McClanahan
has publicly announced that he plans on a seamless integration of JSF
and Struts. The goal is to allow you to replace the use of some of
the Struts tags in your application with UI components of JSF, while
continuing to utilize the Struts Controller and Action classes. You
might imagine how a JSF Front controller could pass a request on to
the Struts RequestProcessor to perform some
business service on its behalf. This process is indicated in the
"Invoke application" step in Figure 18-1.