Evolution of MVC Architecture
1. No MVC
2. MVC Model 1 (Page-centric)
3. MVC Model 2 (Servlet-centric)
4. Web application frameworks, Struts
5. Standard-based Web application framework?
Java Server Faces (JSR-127)
Now when we talk about Web application framework, we are basically talking about the evolution of MVC architecture, which stands for Model, View, and Controller.
So in the beginning, we used no MVC. Then we had JSP Model1 and Model 2 architecture. And people came up with so called Web application frameworks such as Apache Strut based on Model 2 architecture. And finally we are at the phase there will be a standard based Web application framework.
What is & Why JSF?
In short, JSF is a server side user interface component framework for Java technology based Web applications.
Please note that it is server side instead of client side framework. What this means is that, in JSF architecture, many things that are related to UI management are handled at the server instead of at client side. Of course, the prime example of client side UI framework is Swing.
Please also note that JSF is a UI component framework. What this means is, under JSF architecture, UI is handled by a set of UI components as we will learn later on. The concept of UI component is very important in understanding JSF.
What is JSF?
In a bit more technical definition, JSF is a specification and reference implementation for Web application development framework. And the specification defines various things such as UI component model, event and listener model, validator model, back-end data integration model.
The goal of JSF is to allow tool vendors to provide easy to use tools leveraging JSF underneath so that developers can build Web applications using, for example, drag and drop model as they do in standalone Swing based applications. And a good example of the tool that leverages JSF underneath is Sun Java Studio Creator.
Why JSF?
Now let's talk about value propositions of JSF. You can consider JSF provides the MVC based Web application framework. Again it provides clean separation of roles as we
will talk about later in this presentation. JSF is easy to use. And it provides UI component framework which is extensible. It also provides rendering architecture in which UI components can be associated with multiple renderers. JSF is also designed with multiple client types in mind.
One of the greatest advantages of JavaServer Faces technology is that it offers a clean separation between behavior and presentation. Web applications built with JSP technology partially achieve this separation. However, a JSP application cannot map HTTP requests to component-specific event handling or manage UI elements as stateful objects on the server. JavaServer Faces technology allows you to build Web applications that implement finer- grained separation of behavior and presentation traditionally offered by client-side UI architectures.
The separation of logic from presentation also allows each member of a Web application development team to focus on their piece of the development process, and provides a simple programming model to link the pieces together. For example, Page Authors with no programming expertise can use UI component tags to link to application code from within a Web page without writing any scripts.
Another important goal of Java Server Faces technology is to leverage familiar UI- component and Web-tier concepts without limiting you to a particular scripting technology or markup language. While Java Server Faces technology includes a JSP custom tag library for representing components on a JSP page, the Java Server Faces technology APIs are layered directly on top of the Servlet API. This layering of APIs enables several important application use-cases such as: using another presentation technology besides JSP pages, creating your own custom components directly from the component classes, and generating output for different client devices.
Most importantly, Java Server Faces technology provides a rich architecture for managing component state, processing component data, validating user input, and handling events.
· JSP and Servlet
– No built-in UI component model
· A few words on Struts first
– I am not saying you should not use Struts
– Struts and JSF can be used together
· Struts
– No built-in UI component model
– No built-in event model for UI components
– No built-in state management for UI components
– No built-in support of multiple renderers (Struts is more or less tied up with HTML)
So in summary, why do we need JSF when we have Servlet and JSP? Furthermore, why do we need JSF when we have a popular web application frameworks such as Struts?
As was mentioned, JSP and Servlet do not provide built-in UI Component model.
What about Struts? Struts is designed with a different focus. The focus of Struts is to provide a controller framework while the focus of JSF is to provide UI component framework. So Struts does not provide the built-in UI component model. And because of that, it does not support UI component event model, nor state management of UI components, and because Struts is more or less tied up with HTML, it does not support the independence between UI components and a particular renderer.
JSF Design Goals
· Tool friendly
· Client device / protocol neutral
· Usable with Java Server Pages (JSP)
· Usable without JSP
· Useful in the context of HTML and today's browsers
· Scalable
When JSF expert group started working on JSF specification, they had a few things in mind.
First, JSF should be tool friendly. If you think about how developers are building Swing application, they don't write their apps directly using Swing APIs. Instead, they would use an IDE in which they can do drag and dropping UI widgets. And the JSF expert group expect the same thing for building Web applications. They expect tool vendors will provide a way in which developers can drag and drop UI widgets for building Web applications.
The next goal is to make JSF to be client device and protocol neutral. That is, there has to be a clean separation between UI component model and how UI components are rendered to a particular client using a particular protocol. Of course, HTML browser using HTTP protocol is the most pervasive form of client device and protocol and they should be well supported. But the point is the UI component model should be able to accommodate other client types and protocols easily as they come.
JSF 1.x uses JavaServer Pages (JSP) for its display technology, but can also accommodate other technologies (such as XUL and Facelets). JSF 2 uses Facelets by default for this purpose. Facelets is a more efficient, simple, and yet more powerful view description language (VDL).
| |
As I mentioned, JSF provides User interface framework, which runs on the service side.
Let's say a client makes a request. The request goes across the network to the server, where JSF framework builds up UI representation and renders back to the client in whatever mark up language that is appropriate to the client.
The user interacts with that page, and submit a request to the server for processing. The JSF framework then interprets the request parameters, and decode them and converts them into events and dispatch them to event handling logic.
This picture shows JSF architecture in a somewhat simplified manner.
Just like any other MVC-based architecture, JSF architecture has its own Front controller called FacesServlet. The role of this controller is basically a gatekeeper.
As we will learn later on, a JSF page is made of a tree of UI components. These UI components can be associated with backend model objects called backing beans. These backing beans handle application logic (or sometimes called business logic) handling.
When a page has to be rendered to a particular client type, whether the client type is a HTML browser running on a desktop or WML browser running on a wireless phone, a particular renderer is used for displaying the data maintained in the UI components. In other words, a same UI component is used for displaying information on different client types using different protocols.
Important Basic Capabilities
· Extensible UI component model
· Flexible rendering model
· Event handling model
· Validation framework
· Basic page navigation support
· Internationalization
· Accessibility
So just to repeat the important JSF features and capabilities here one more time, JSF UI component model is extensible. That is, you as a developer can use the built-in UI components that come with a typical JSF implementation or you can extend them. JSF also provides flexible rendering model as was mentioned. That is, UI components in JSF are not tied with a particular rendering technology such as HTML. This means any rendering technology can be used for displaying information maintained in the UI components.
JSF also supports event handling model. For example, when you click on a UI component on a JSF page, it will generate an event and any server side programs which registered to receive event notifications will be notified.
JSF also supports page navigation through a configuration file. In this sense, this is quite similar with Struts.
JSF also supports internationalization and accessibility.
Key JSF Concepts
UIComponent
Render-independent characteristics, Base class with standard behaviors
Standard UIComponent Subclasses:
UICommand, UIForm, UIGraphic, UIInput, UIOutput, UIPanel, UISelectBoolean, UISelectMany, UISelectOne
FacesEvent
Base class for request and application events
Validator
Base class for standard and application defined validators
So let's go over some of the key JSF concepts. Again, we talked about these concepts already a bit.
First, the concept of UI component is extremely important for you to understand. I would say that if you understand the concept of UI component, you understand
90% of JSF architecture.
Converter
Plug-in for String-Object conversion
FacesContext
- Servlet request, response, session, JSF request, response trees
- Model reference expression evaluators,Syntax similar to the expression language of the JSP Standard Tag Library (JSTL) 1.x ,Primary interface between components and the data provided by (or to) the application
Renderer
– Converts components to and from a specific markup language
– Supports render-dependent attributes on components
– May support more than one component type
RenderKit
– Library of Renderers
– Extensible at runtime
– Basic HTML RenderKit is part of the specification
Because of the division of labor enabled by the JavaServer Faces technology design, JavaServer Faces application development and maintenance can proceed quickly and easily.
The members of a typical development team are those mentioned in the picture above. In many teams, individual developers play more than one of these roles, however, it is still useful to consider JavaServer Faces technology from a variety of perspectives based on primary responsibility.
JSF specification implementations
· IceSoft’s Ice Faces
· Apache’s MyFaces
· Oracle’s ADF Faces
· JBoss RichFaces.
In next article, we will go through more on developing the application, deploying the application.
No comments:
Post a Comment