In this article, the author Anand Joshi explains the JavaServerTM Faces (JSF) architecture using the design pattern in the JSF framework. He discussed the GOF design pattern used in the JSF architecture, and the role of these modes in the JSF framework. Anyone who has a certain understanding of the design mode and JSF architecture can be gathered from anand detailed introduction. * Readers should have a good understanding of GOF design patterns and JSF technology.
Design patterns can help users abstract detail at higher levels, better geographical architecture. If you are more familiar with the GOF Design Mode and the JavaServer Faces (JSF) framework, this article can help you inspect the design patterns used in the JSF framework and understand its working principle.
This paper explores the design pattern used in the JSF framework. Detailed design patterns include Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer mode.
Design mode and JavaServer Faces (JSF) technology
First briefly introduce the mode and JSF framework.
mode. The design pattern is a universal applicable method for problems and solutions. Because the mode is recognized by all developers and architects, mode can save time and resources. In terms of an outway, the mode is a verified solution about the problem known to a person. The model can be reused, reuse makes the solution more robust. Java Server Faces. The JSF architecture is a web application framework. It is a standard framework for Java Community Process (JCP) and is expected to be a standard framework for web applications. There are more than 50 frameworks currently used to develop web applications. This shows that there is an urgent need to standardize the framework, this is the goal of the JSF framework!
In-depth analysis of JSF mode
Now let's discuss various design patterns in the JSF architecture. This article will discuss in detail Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer design mode. I will analyze the use of each mode and its role in the JSF framework.
Singleton mode
The purpose of the Singleton mode is to ensure that only one instance is loaded, which provides a global access point. When starting a web application with JSF support, the web container initializes a FacesServlet instance. At this stage, FacesSrvlet instantiate Application and Lifecycle instances for each web application. These examples use well-known Singleton mode, usually only one example of this type.
Use JSF web applications only require an instance of Application and Lifecycle classes. Lifecycle manages the entire life period of multiple JSF requests. Because of its status and behavior sharing between all requests, these objects use the Singleton model reasonable. Phaselisteners, which is Lifecycle maintained is also a Singleton mode. Phaselisteners is shared by all JSF. Singleton mode can be widely used in the JSF framework to reduce overall access to memory and provide objects. NavigationHandler (logical results for determining the request) and ViewHandler (for creating views) are also examples using the Singleton mode.
Model-View-Controller (MVC)
The purpose of the MVC mode is to separate data (ie, model) from the data representation (virtue). If the application has a variety of representations, only the view layer is replaced and reuse the controller and model code. Similarly, if you need to change the model, you can do not change the view layer to a large extent. The controller handles user actions, and user actions may cause model changes and view updates. When the user requests a JSF page, the request is sent to the FacesServlet. Facesservlet is the front-end controller servlet used by JSF. Like many other web application frameworks, JSF uses the MVS mode to eliminate coupling between views and models. In order to centralize user requests, the controller servlet changes the model and navigate to the view. Facesservlets are controller elements that all user requests in the JSF framework. Facesservlet analyzing user requests, using managed beans to call various actions on the model. Backing or Managed bean is an example of this model. The JSF User Interface (UI) component is an example of the view layer. The MVC mode decomposes tasks to developers with different skills, so that these tasks can be performed simultaneously, so the GUI designers can create JSF pages using rich UI components, and the backend developers can create managed beans to write specialized business logic Code.
Factory Method mode
The purpose of the Factory Method mode is to define an interface for creating an object, but the object instantiates delay in the subclass. In the JSF architecture, the Factory Method mode is used to create an object. LifecycleFactory is a factory object that creates and returns a Lifecycle instance. LifecycleFactory's getLifeCycle (String Lifecyclecleid) method uses Factory Method mode, created (if needed), and returns a Lifecycle instance based on LifecycleID. Custom JSF implementation can redefine the getLifeCycle abstract method to create a custom Lifecycle instance. The default JSF implementation provides the default Lifecycle instance. Also, for each JSF request, FacesServlet gets FacesContext from FacesContextFactory. FacesContextFactory is an abstract class that opens the GetFacesContext API, the JSF implementation provides the specific implementation of the FaceSconTextFactory and GetFacesContext API. This is another example using the Factory Method mode, and the specific FacesContextFactory implementation creates a FacesContext object.
State mode
The purpose of the State mode is to allocate logic related to the status between different classes of the state. FacesServlet calls Execute and Render methods for Lifcycle instances. Lifecycle coordinates different phrases to perform JSF requests. Here JSF implementation follows State mode. If this mode is not used, the Lifecycle implementation will be a large number of conditions (ie "if" statement). The JSF implements a separate class for each state (or phase) and calls STEP. Phase is an abstract class that sets the common interface of each step. Six Phrase (ie Step): RestoreViewPhase, UpdateModelvaluesphase, InvokeApplicationPhase, InvokeApplicationPhase, InvokeApplicationPhase, InvokeApplicationPhase, InvokeApplicationPhase In State mode, Lifecycle passes the FacesContext object to PHASE. Each phase or status change is passed to its context information, and then set the flag in the FacesContext itself indicates the next possible step. The JSF implementation changes its behavior in each step. Each stage can be used as a cause of the next stage. FacesContext has two flags RenderResponse and ResponseComplete can change the order of execution. After each step is executed, Lifecycle checks if these flags are set up in the previous phase. If the responseComplete is set, Lifecycle completely waives the execution of the request. If a renderResponse flag is set after a phase, JSF will skip the remaining phases and directly enter the render response phase. If these two signs are not set, Lifecycle will continue to perform the next step in order.
Composite mode
Composite mode allows customer code to handle composite objects and basic objects. Composite objects are containers of basic objects. In the first phase (Restore View phase) and the last phase (Render Response phase), the UI View is constructed using the JSF UI component. UIComponentBase is an example of a Component abstract class in CompositeN mode. UiViewRoot is the Composite class, and UIOUTPUT (in all sides) is the leaves (or basic class). The UIComponentBase class defines a public approach to the leaves and composite objects, such as encoding / decoding values and subpost management functions. The child node management function, such as getChildren, returns an empty list for the leaves node, returns its child node for the composite node.
Decorator mode
The purpose of Decorator mode is to pass the behavior of the subclassified dynamic extension object. The JSF framework has a lot of extensions (ie, insertable mechanisms). The JSF implementation can replace the default PropertyResolver, Variableresolver, ActionListener, NavigationHandler, ViewHandler, or StateManager. Typically custom implementation accepts references to its default implementation via constructor. Custom implementations only rewrite a subset of the function, and other functions are delegated to the default implementation. If you want to implement custom ViewHandler, override the default method calculateLocale ViewHandler implementation may be written as a list of class 1 as CustomViewHandler: Listing 1. CustomViewHandler fragment public class CustomViewHandler extends ViewHandler {public CustomViewHandler (ViewHandler handler) {super (); oldViewHandler = handler ;} private ViewHandler oldViewHandler = null; public void renderView (facesContext context, UIViewRoot view) {// delegate method to oldViewHandler oldViewHandler.renderView (context, view);} // custom implementation of calculateLocale public Locale calculateLocale (facesContext context) {} }
Strategy mode
The purpose of the Strategy mode is to encapsulate different concepts. The JSF framework uses the Strategy mode to use the delegate implementation model to present the UI component. JSF technology supports two rendering models. In the direct implementation model, the UI component decodes the data received in the received request, and then encodes these data to display. In the entrustment implementation model, decoding and encoding operations delegate and set up the associated specialized renderer. The latter model uses the Strategy design mode, more flexible than direct implementation. In the Strategy mode, different algorithms are encapsulated in a separate object, so that the algorithm can be dynamically changed. The JSF implementation can register additional renders with existing renderkit instances. When the application starts, the JSF implements the read configuration file to link these renders and UI components.
Template Method mode
The purpose of the Template Method mode is to delay the steps of changing to the subclass, while defining those fixed algorithm steps in the parent class. The JSF framework exhibits the features provided by the Template Method mode via PhraseListeners. Template Method (or "Hook") allows the web author to provide an implementation for an optional step between different phases, while the main phase is still consistent with the definition of the JSF framework. The JSF framework provides PhaseListeners, conceptually similar to variable steps in the Template Method mode. The JSF framework has six predefined phases, between each stage, the web author can implement Phaselisteners to provide HOOK similar to the Template Method Hook. In fact, this structure is more scalable than the Template Method mode. You can provide HOOK by registering PhraseId's phaselistener's Phaselistener. If the Phaseid is any_phase, the JSF implementation will call this Phaselistener before and after each phase. The implementation of the JSF framework is slightly different because there is no Phaselistener at all, but in the Template Method mode, the subclass usually redefines the abstract variable steps in the parent class. Observer mode
The purpose of the OBServer mode is to automatically notify all dependencies (ie observer) when the status of the target object changes. JSF implements the OBServer mode in the UI component. JSF has two types of built-in events: ActionEvent and ValueChangeDevent. ActionEvent is used to determine the activation of user interface components (such as buttons). When the user clicks the button, the JSF implementation notification is added to one or more action listeners on the button. Then the button is activated, or the state of the button (main body) changes. All listeners (ie, the observer) added to the button receive notification the main body state has changed. Similarly, the JSF implementation notifies the ValueChangeListener when the value in the input UI component changes.
Conclude
The JSF framework takes advantage of Singleton, Model-View-Controller, Factory Method, State, Composite, Decorator, Strategy, Template Method, and Observer design mode. Because its architecture is based on a verified design pattern, this is a robust framework, and it is a good utilization in the JSF framework.
Reference
Learn
You can see this article in our website on our world. Please visit Gang Of Four Design Patterns to learn more about these design patterns. Please read the "Skeptical JSF: The Life Cycle of JSF Apps" to learn more about the JavaServer Faces framework (developerWorks, March 2005). Please visit the developerWorks Java technology area. Here is articles and tutorials that are based on Web and Java-based solutions.
