JSF Central - Designing JSF Applications: a Storyboard Approach — Part 2
JSF Central

 
 Home 
 
 Products 
 
 Articles & Books 
 
 Resources 
Designing JSF Applications: a Storyboard Approach
 
Designing JSF Applications: a Storyboard Approach — Part 2
by Steven L. Murray
28 Aug 2009 02:30 EDT

In the second article of this series on using storyboard design for Web applications, Steven Murray explains how to map the Storyboard design to a JSF implementation, giving special attention to Storyboard Controllers.


In part 1 of this series we discussed how to create storyboard designs for Web applications. In part 2 we are going to focus on how to map the design to a JSF implementation, giving special attention to Storyboard Controllers.

Controllers are the heart of the presentation tier, where they manage the behavior of the UI and direct the flow of information between the presentation and business models. Almost every article I read on JSF, and even the specification itself, references Model View Controller (MVC) without providing any concrete examples on how to actually use it in a JSF project. I hope to change that with the introduction of the Presentation Model.

Presentation Model

The Presentation Model is based on the MVC pattern called Separated Presentation. The premise of the pattern is quite simple: you place the presentation and domain code into separate layers that have strict visibility rules, which allow the presentation to call the domain but the domain remains completely unaware of the presentation. There are two basic ways that you can implement a controller using this pattern. The first is called Supervising Controller. In this technique you are permitted to use data binding to communicate directly between the view and the domain model; this is the common pattern you see promoted in JSF examples. The problem with the Supervising Controller is that often the view logic can be complex and difficult to manage. The preferred pattern for a storyboard design is to use a Presentation Model, which is illustrated in figure 1.

  Figure 1. Presentation Model
Figure 1. Presentation Model

A presentation model pulls the state and behavior of the view out into a model class that encapsulates access to the domain model and provides a public interface that is consumed by the view. The key features of the presentation model are:.

  • The presentation state is in the model
  • The presentation logic is in the model
  • The view observes the model and updates accordingly
  • The model does not know about the view

The motivation is to create controllers that manage their own state and interact with each other when necessary.

Mapping the Storyboard design to the Presentation Model

The mapping begins with the assignment of a presentation model to each of the screens or compartments in a storyboard design, as shown in figure 2. The model should contain an accessor attribute for each field and a method for each operation specified in the design. A single presentation model can be shared between one or more views.

  Figure 2. Mapping the Storyboard to the Presentation Model
Figure 2. Mapping the Storyboard to the Presentation Model

Consider the presentation model as an abstraction of the view that is not dependent on a specific view framework or rendering mechanism. It is a self-contained class that represents all of the data and behavior of the UI window, but without any of the components used to render that UI on the screen. The view simply renders the state of the presentation model on to the screen.

Let’s discuss the presentation model using some of the common JSF terms you might have heard or read about.

Backing Bean

A backing bean is a plain old Java object (POJO) that implements the JavaBean convention and is associated with User Interface (UI) components in a view. In JSF, a backing bean is typically described as having three main functions:

  • It can hold references to the components used in the view and make them available to the controller(s) during the JSF Lifecycle process.
  • It provides the properties (data) that define the components in the view: their look and feel, behavior, and the data used to render themselves within the view.
  • It exposes methods that can be used by the components to communicate user interaction events back to the server.

The presentation model at its core is a backing bean and carries out each of these basic functions. I like to think of the presentation model as giving purpose to backing beans. The presentation model is not revolutionary; rather it provides a well defined pattern for deploying backing beans to create rich JSF applications. Let's look at these functions in greater detail and how they relate to the presentation model.

Component Bindings

Each page in a JSF application is called a View and is represented by a hierarchical component tree that begins with the view root (UIViewRoot). A component binding allows you to place a reference to a component within the view tree directly into a backing bean using the tag attribute binding. This pattern is supported by most JSF visual development editors (VDEs) by providing a special request-scoped backing bean for this purpose as shown in figure 3.

  Figure 3 Component Binding
Figure 3 Component Binding

A component binding provides direct programmatic access to view components when required.

The binding signature looks like:

UIInput inputComponent; public void setInputComponent(UIInput inputComponent) { this.inputComponent = inputComponent; } public UIInput getInputComponent() { return inputComponent; }

I have had a few rare occasions where I needed a component binding, and recommend disabling the auto-creation of them in your Visual Development Editor (VDE).

Value Expressions

While not every component attribute is a value expression (e.g. id) the vast majority of attributes supported by JSF components are manipulated using value expressions. Value expressions bind the attributes of a UI component to properties (setters and getters) provided by the backing bean. The data type specified by the attribute in the storyboard design should be equivalent to the data type exposed by the property in the backing bean. The typical value expression looks something like:

private String answer; public void setAnswer(String answer) { this.answer = answer; } public String getAnswer() { return answer; }

There are a variety of standard attribute types supported by JSF component types, ranging from CSS styles (style, styleClass) to the actual business data (value)being displayed and/or input. The standard definition of a backing bean does not give you much guidance on how to implement the complex Rich Internet applications we build with JSF.

The presentation model pulls the state of the view into a model class that is part of the presentation. The approach tells you to map each attribute directly to your presentation model and places the responsibility of mapping (or synchronizing) the presentation data to the domain model with the presentation model. This is a departure from most of the backing bean examples you see in JSF, where the view components are often shown to be mapped directly to the domain model.

In our view we would use the value expression #{presentationModel.answer} to access the property answer that is held by the presentation model. It is the job of the presentation model to initialize that state from the domain model, if required, and to persist the presentation model state back into the domain model when required. In future articles I hope to convince you that this extra layer is well worth the work -- and in many cases it’s not all that much work -- as we investigate strategies for integrating with your existing business logic and data.

Conversion and Validation

The value attribute, supported by all data components (UIOutput, UIInput), deserves special attention. The value attribute is used to specify the data content, used by a component, to be displayed to the user and optionally read as input from the user. There are two special operations associated with the value attribute that are of special interest: conversion and validation. Conversion is the process of transforming from a client-side String to a server-side data type and back again as the data is shuttled to and from the presentation. Converters always operate on data types (classes) and are external to the presentation model

Validation is the process of evaluating input data, submitted for a component, against the constraints specified in your storyboard design. Validation always occurs after conversion. I like to keep these constraints targeted to the presentation logic; you should avoid the temptation to use validation for more complex business (use-case) logic. Business validations should be performed by your domain model during the Invoke Application phase.

  Figure 4 – Value Expressions
Figure 4 – Value Expressions

JSF validators are realized by the presentation model, which is responsible for enforcing the presentation constraints. A representative diagram is shown in figure 4.

Method Expressions

Method expressions support the arbitrary invocation of a public method on a backing bean, passing a specific set of parameters and returning a value (if any). Method expressions are used to communicate events from the view to the presentation model. In JSF there are a variety of events, including action, value change, and phase.

  Figure 5 Method Expressions
Figure 5 Method Expressions

In a storyboard design, operations are mapped to action and value change events. All events, with the exception of phase events, will contain a UIComponent reference allowing you to easily identify the source of the event. JSF events should normally be mapped directly to your presentation model as shown in figure 5. Action events are sent to the model in response to a user gesture, such as clicking on a button, and are typically generated using a form submission. Value change events occur when the (submitted) value of a component has changed; they are generated by the JSF Front Controller. Either of these events can be dispatched via AJAX requests, and is the mechanism that will power your Rich Internet application designs.

It is through method expressions that the controller part of our presentation model processes user input, and in turn manipulates the view in order to implement the view logic. It accomplishes this by implementing a state machine, whereby an action event plays the leading role, and value change and phase events supporting roles. Each action event encapsulates a single server-side transaction that results in a presentation model state change. Value change events are notification markers used to inform the model when client-side data has been altered. Phase events are positional markers used to inform the model of the state engine process location within the JSF Lifecycle.

The power of the presentation model pattern comes from its realization of a view controller. It manages both the state and behavior of the presentation and determines how and when the view interacts with the domain model.

Managed Bean

A managed bean is a Java object that implements the Java Bean pattern. It is created using a Dependency Injection container, accessed using value and method expressions, and has a life cycle that is managed by the framework. In JSF, all backing beans are (usually) managed beans. In a storyboard design, the presentation model, as well as the storyboard and composite models that will be introduced in part 3, are implemented as managed beans, as shown in figure 6.

  Figure 6 Managed Bean
Figure 6 Managed Bean

In a storyboard, it is the job of the presentation model to determine how to initialize the view state, persist that state between the screen transitions, and determine when to update the domain model. I am going to defer this discussion to part 4 where we will begin to touch on how these types of beans should be used in a storyboard design.

JSF Lifecycle

The life cycle is not really all that difficult to understand, but you do need to know its principles in order to be successful with JSF and implement a presentation model. In this section I will try to simply the life cycle and will present it using a different perspective. Namely I will describe the life cycle as the implementation of a state machine, using a sequence diagram, with particular focus on how this state machine interacts with the presentation model just described.

State Machine

JSF has a well defined state engine, in which the JSF Front Controller plays the leading role and is assisted by the components and the presentation model(s) in your view. The steps executed by the state machine are called phases, and these phases comprise what is typically called the request processing life cycle. One execution of the life cycle completes one state transition of the model. The JSF State Machine has the following characteristics:

  • JSF has an inherent controller architecture that begins with the JSF Servlet. This Servlet delegates control to the JSF Lifecycle, which implements the Front Controller pattern for JSF web applications. The life cycle is responsible for processing the request, executing the state engine, and rendering the response.
  • Each component used in a view implements a controller. This component controller is responsible for maintaining the component’s state and rendering its presentation to the target device in the assembly of the user interface. Often, rendering is delegated to a separate Renderer class specific to a presentation technology (e.g. HTML, WML, Flex).
  • Each presentation model assigned to a view implements a controller. This view controller is responsible for maintaining the view’s state and executing the view logic associated with a screen.
  • The front, component, and view controllers collaborate together during the execution of the life cycle, implementing the presentation model MVC pattern in our storyboard implementation.

The implementation of the presentation model is the responsibility of the JSF application developer. Understanding what happens during each step of the life cycle and how the model collaborates with the other controllers servicing the state engine is key to delivering rich JSF applications.

A full diagram of the state machine is included in the appendix of this article. The remainder of this section will present the machine in sections corresponding to the phases of the life cycle.

Restore View

The first phase of the life cycle is Restore View and it is always executed. The purpose of this phase is to restore the state of the components used in the view being requested and, if there are any bindings, set the component reference into the corresponding backing bean. Should you need direct access to any component interfaces, you should place a reference to those component(s) in the presentation model as shown in figure 7.

  Figure 7 Restore View
Figure 7 Restore View

It is important to remember that the Front Controller stores the state of the components between transitions, but does not provide a mechanism to store the state of the presentation model. You can store the state of the presentation model between the response and next request by setting the scope of the model’s managed bean to Session. We will discuss more robust approaches (Conversation, Page) in part 4.

Apply Request Values

Under normal conditions the only processing that occurs during the Apply Request Values phase is to associate the submitted form parameter(s) with the appropriate input component(s) as shown in figure 8.

  Figure 8 Apply Request Values
Figure 8 Apply Request Values
Controlling the State Machine

There are three primary mechanisms for controlling the state machine, associated with the processing steps in the JSF Lifecycle. These are:

  • Immediate Attribute
  • Render Response
  • Response Complete

The immediate attribute affects only the Apply Request phase, while the Render Response and Response Complete are programmatic directives that can be used in this or any one of the remaining life cycle phases. Here is a brief explanation of these control mechanisms.

Immediate Attribute

One of the most misunderstood and often frustrating JSF state machine control mechanisms is the immediate attribute. Setting an input component’s immediate attribute to true will modify state machine processing by moving the component's conversion, validation, and value change events from the Process Validation phase to the end of Apply Request Values phase. The processing of all remaining components not having the immediate attribute directive occurs normally in the Apply Request Values phase.

Often overlooked are action events associated with these components, which would typically be called in the Invoke Application phase; they are also invoked prior to completing this step. Think of the immediate directive as selectively executing (without phase events) the Apply Request, Process Validation, and Invoke Application phases on only those components that use the directive. It is important to also note that the presentation model is never updated when using this directive in the Apply Request Values phase.

This behavior can either be a friend or foe in the implementation of your presentation model. It can be extremely powerful when properly used to your advantage and can lead to many bugs when it is not. As is true in the implementation of any state machine, once you understand what happens at each step the machine takes, you can usually architect an appropriate solution to carry out the desired behavior.

The most common use case is the Cancel path. In this scenario you do not want to perform any conversion or validation that would occur normally when processing the page. The user does not want to see any page errors; they simply want to get out of the page. The immediate attribute moves the processing of the Cancel flow to the beginning of the state machine processing, allowing you to bypass all of the other page processing. This concept can also be useful in processing AJAX events when you only want to focus on the component associated with the user interaction. However, having too many components using the immediate directive can lead to presentation logic conflicts.

Render Response

The Render Response programmatic control mechanism will cause the state machine to proceed to the Render Response phase at the completion of the currently executing life cycle step. This directive is often used in conjunction with the immediate attribute to process an event from a single component, update the presentation model state, and then bypass any remaining processing steps and proceed directly to render the response.

Note: When you use the immediate and render response directives together and need to store any altered data from the component into your presentation model, then you need to use the ValueChangeEvent to capture the data and manually update your model.

Response Complete

The Response Complete programmatic control mechanism is similar to Render Response except that it immediately ends the lifecycle, terminating any remaining output. This can be used in those circumstances when you want to process a client side AJAX event but do NOT want to update the presentation or intend to output data yourself – such as binary data.

Both Render Response and Response Complete are calls associated with the FacesContext.

Process Validations

The Process Validations phase is responsible for taking the form values submitted in the Apply Request Values phase and performing the following actions, illustrated in figure 9:

  • Convert submitted values from a String to their target data type
  • Validate that the values submitted comply with all of the constraints defined
  • Generate value change events when the submitted data is found to be different from what is held in the presentation model
  • Set the local value of the component
  Figure 9 Process Validations
Figure 9 Process Validations

Update Model Values

It is during the Update Model Values phase that the submitted data is then moved to the presentation model, as shown in figure 10.

  Figure 10 Update Model Values
Figure 10 Update Model Values

The Front Controller transfers the component’s local value, set during conversion, to the presentation model through a value binding. It then will clear the local value.

In the storyboard design it is important to remember that the “model” is the presentation model and not the domain model. A common storyboard pattern will be to delegate the update (setter and getter) to an Entity Bean (e.g. Hibernate, JPA, Web Bean). This will be discussed in greater detail in part 4.

Invoke Application

The Invoke Application phase delivers the action event to the presentation model and executes the business logic, as shown in figure 11.

  Figure 11 Invoke Application
Figure 11 Invoke Application

At the beginning of this phase, you should perform all of your remaining high level and/or complex presentation validations that were not handled in the Validation phase. It is not the job of the presentation model to perform the majority of your business validations; this logic should reside within your domain model.

When using AJAX you may execute the state machine several times before an update to the domain model is required. When this happens is based on your presentation requirements; it is the responsibility of the presentation model to synchronize with the domain model at the appropriate check points. It is at these decision points that you execute the business logic required by the user action and change the state of the domain model.

It is also during this step that the presentation model determines the next navigation step, if any, to be executed by the application.

Render Response

The Render Response phase is the sixth and last phase of the life cycle, and is responsible for delivering the presentation (HTML) to the screen. During this phase each component will make a call into the presentation model in order to retrieve the data they need in order to render the component, as shown in figure 12.

  Figure 12 Render Response
Figure 12 Render Response

When rendering a response, each component writes its representation, through the appropriate render kit, for display on the presentation device.

Conclusion

The presentation model contains the state and behavior of the view and coordinates with the domain model in order to implement the view logic. The presentation model represents an abstraction of the view and can be thought of as a representation of the user interface. It is implemented as a fully self-contained class that represents all of the data and behavior of the screen and orchestrates how controls will render the UI on the screen. The view then simply projects the state of the presentation model onto the glass -– this is exactly how JSF has been designed to work.

The presentation model will have all of the data fields necessary for the dynamic generation of the view. This means that it will include all of the input form data used by the components that comes from the domain model, as well as information that may be directly associated with the functioning of the view itself (e.g. check box controlling visibility of a region).

In part 3, I will complete the storyboard with the introduction of the storyboard and composite models. These models are similar to the presentation model and are used to implement the use-case and compartments used in our storyboards. Then in part 4 we will begin to look at how these three models interact with the domain model.

Appendix

  Figure 13 Full JSF Lifecycle Sequence Diagram
Figure 13 Full JSF Lifecycle Sequence Diagram

Resources



RSS feed(all feeds)

The Editor's Desk
Podcasts
Inside Facelets
In the Trenches

Site version 1.83  Report web site problems

Copyright (C) 2003-2014 Virtua, Inc. All Rights Reserved. Java, JavaServer Faces, and all Java-based marks are trademarks or registered trademarks of Oracle Corporation. in the United States and other countries. Virtua, Inc. is independent of Oracle Corporation. All other trademarks are the sole property of their respective owners.