|
|
|
|
|
Overview:
|
|
JSF (Java Server Faces) is a user interface framework for Web applications using Java technology. Designed to ease the burden of developing and maintaining applications that run on Java application servers and render their UIs back to a target client, JSF leverages existing, standard UI and Web-tier concepts without limiting developers to a particular markup language, protocol, or client device. Sun Microsystems initiated JSF technology as JSR 127 in 2001.
|
|
JSF includes two main components:
|
- Java APIs for UI component management, UI state management, event handling, input validation, page navigation, internationalization, and accessibility
- A JSP custom tag library for expressing the JSF interface within a JSP page
|
|
Benefits:
|
|
JSF simplifies UI development in several ways:
|
- Makes it easy and fast to create a UI from a set of predefined UI
components.
- Automatically manages UI state.
- Facilitates object-oriented development. JSF is based on
the Model-View-Controller (MVC) architecture, which offers a clean
separation between logic and presentation.
- Enables developers to create custom UI components and reuse them.
- All the above functionality is available via standard Java APIs, and
thus not tied to JavaServerPages (JSP).
|
|
Popularity and Maturity:
|
|
JSF is heavily supported by SUN and it is seen as the new J2EE standard for developing web applications. As JSF is still new and in initial stages so there are and will be bugs and issues but the good part is that there are people working actively on fixing these and the new 1.0 release looks quite stable. With all the support form leading names in web application development very soon JSF will reach a stable state. JSF tutorial is now available under J2EE 1.4.
|
|
As of now the community of JSF users is much smaller than Struts but with all the thrust from big names like Sun, Oracle and various IDE Vendors it won't be long before JSF penetrates the web application community. The acceptance of even the beta release goes on to show that this is something which was missing from Web Application Development scene and people are seeing the value, this object oriented approach brings, to the world of Web Programming.
|
|
Features and concepts:
|
|
Component Model:
|
|
JSF defines the UI in terms of components. This is a big step towards bringing object oriented approach to web programming. A web application is seen as a set of components and event listeners associated with them.
|
|
Framework provides some common generic components to do necessary repeatable tasks but the real value lies in creating your own custom components.
|
|
JSF components can be associated with events listeners. So from UI, events can be linked directly to these components and now these components can be treated as individual units along with all their event listeners.
|
|
This also brings in another advantage of this components approach. Each component now can be tested individually as stand alone programs.
|
|
This object oriented approach in web based application is something that makes JSF unique and is a big plus over simpler frameworks like Struts or WebWork.
|
|
Life Cycle Processing Model:
|
|
|
In contrast to typical stateless Web applications in JSF the UI is constantly represented by a framework managed component tree. This characteristic gives JSF applications the ability to handle events and state changes in the same manner a traditional, thick-client Java application would.
|
|
Another plus is that very soon vendors will be coming with lots of usable components and even the open source community will soon come up with new components.
|
|
Separation of Roles:
|
|
JSF provides a clear separation of roles involved in Web Application Development. JSF makes it possible to divide the application development process into distinct roles so that different people can contribute to different parts of the process. Even if the same person plays more than one of these roles, it is still useful to understand the individual perspectives separately.
|
|
Component writers:
|
|
A component writer is someone who creates reusable user interface components. These components are stand alone units and can be tested individually and written by someone with no knowledge of html etc.
|
|
Application developers:
|
|
An application developer provides the server-side functionality -- model objects, validators and event handlers, and so on. In an MVC scenario, the person filling this role provides both model and controller parts.
|
|
Page authors:
|
|
A page author is someone who uses markup language to author pages for Web applications. Responsibilities include using markup languages, doing graphic design, assembling content of pages, and using tags.
|
|
Rendering of components:
|
|
JSF introduces the concept of separating rendering of the component to something called Renderer. This essentially means that now components can be generic and not bound to any specific mark-up language. So if you want to display the same component in HTML and WML all you need to do is write a separate Renderer for both of these markup languages without the need to modify the existing component. Again this is a big plus over Struts.
|
|
Validations:
|
|
JSF provides two levels of validations. One is the field level validations and other the business validations. The framework itself provides extremely useful field level validation capabilities. These validations range from 'Required Field' to 'Number Check'.
|
|
As these validations need not to be defined before hand in an xml file we have the luxury of defining our validations next to form fields using tags which gives an easy way to define validations for forms with dynamic fields.
|
|
The following validators are provided by JSF:
|
|
Length Validator:
|
|
Tag: <f:validateLength>
|
|
Attributes: minimum (minimum value allowed)
|
|
maximum (maximum value allowed)
|
|
Long Range Validator:
|
|
Tag: <f:validateLongRange>
|
|
Attributes: minimum (minimum value allowed)
|
|
maximum (maximum value allowed)
|
|
Double Range Validator:
|
|
Tag: <f:validateDoubleRange>
|
|
Attributes: minimum (minimum value allowed)
|
|
maximum (maximum value allowed)
|
|
JSF Required Field Validator:
|
|
This is a required field check validator to check if the field value is null.
|
|
The usage of this validator is
|
<h:inputText id="firstname" value="#{userBean.firstname}" required="true"/>
|
|
Custom Validator:
|
<h:inputSecret id="password" value="#{userBean.password}">
|
<cfm:password_validator>
|
</h:inputSecret>
|
|
The custom validators can be implemented easily by implementing Validator interface provided by JSF. There is one validate method which needs to be implemented. In the example above the password_validator is implemented by PasswordValidator.java
|
public class PasswordValidator implements Validator {
public void validate(FacesContext context, UIComponent component,
Object toValidate) { }
}
|
|
Furthermore you can choose to put this validate method in your Beans if that makes business sense. So in the above case you may want to put password validation in User Authentication bean.
|
|
Conversions:
|
|
JSF provides a mechanism to have your own conversion logic plugged into the components so that the data inputted by user can be converted before it reaches the processing logic. Also the data to be shown to the user can be passed thru these converters to change it to displayable format. There are some basic converters provided by the framework itself to do various field level conversions. These can be associated easily with basic html elements like text fields etc. using jsf tags.
|
|
Below is the list of converters provided by JSF:
|
|
BigDecimalConverter
|
|
BigIntegerConverter
|
|
BooleanConverter
|
|
ByteConverter
|
|
CharacterConverter
|
|
DateTimeConverter (has a separate tag <f:convertDateTime>)
|
|
DoubleConverter
|
|
FloatConverter
|
|
IntegerConverter
|
|
LongConverter
|
|
NumberConverter (has a separate tag <f:convertNumber>)
|
|
ShortConverter
|
|
To use these converters you can refer to them via 'converter' attribute of component tag
|
|
<h:inputText value="#{userBean.salary}" converter='FloatConverter' />
|
|
or use <f:converter> tag and refer to the converter by its 'converterId'
|
|
<h:inputText value="#{userBean.salary}" converter='FloatConverter'>
|
|
<f:converter converterId='FloatConverter' />
|
|
</h:inputText>
|
|
or use the tags provided (only for NumberConverter and DateTimeConverter)
|
|
<h:inputText value="#{userBean.createdate}">
|
|
<f:convertDateTime />
</h:inputText>
|
|
Custom Converter:
|
|
The custom converters can be implemented easily by implementing Converter interface provided by JSF. There are 2 methods which need to be implemented.
|
public class MyConverter implements Converter {
public Object getAsObject(FacesContext context, UIComponent component,
String newValue) throws ConverterException {}
public String getAsString(FacesContext context, UIComponent component,
Object value) throws ConverterException {}
}
|
|
In the JSP page you can use this as
|
|
<h:inputText value="#{userBean.address}" converter="MyConverter" />
|
|
Beans:
|
|
JSF does not need a form bean for every UI form created. It allows you to use as many and as little beans as you need for creating your form. What this means is now you can have a page constructed from more than one bean and essentially your UI page is not tied to any particular bean. Your beans can be modeled independent of the UI pages.
|
|
Also JSF introduces the concept of manager-beans. These beans are managed by the framework so you don't need to worry about creation, removal and other basic tasks for using these beans.
|
|
These managed beans are defined in faces_config.xml file and they can be stored within request, session or application scope.
|
|
Tags:
|
|
JSF provides a variety of tags which can be used for performing various common tasks.
|
|
The html tags provided by JSF for creating html elements accept almost all the parameters needed to display them.
|
|
Expression Language:
|
|
JSF uses the JSTL EL. This EL has basic object graph traversal, but relatively weak collection and indexed property support.
|
|
I18N:
|
|
JSF supports passing parameters to the message being constructed. Support is provided for all validation error messages and other exception messages to be internationalized by use of Java Resource bundles.
|
|
Comparison with Struts/WebWork:
|
|
Below is the tabular representation of this comparison study:
|
| Feature |
JSF |
Struts |
WebWork |
| Component and Event Listener Model |
Yes |
No |
No |
| Separation of rendering from the Components |
Yes |
No |
No |
| Form Field Validations |
Yes - do not need prior definition of field names and corresponding validations in xml file |
Yes - needs prior definition of field names and corresponding validations in xml file |
Yes - needs prior definition of field names and corresponding validations in xml file |
| Unit Testability |
Yes - Components can be tested independently as pure java |
No |
Yes - Actions can be tested by instantiating action, setting the properties, and executing them |
| Managed Beans |
Yes |
No |
No |
| Expression Language |
Yes - JSTL EL |
Yes - JSTL EL |
Yes - OGNL |
| Type Conversions |
Yes - provides variety of converters out of the box |
No - need to write your own |
Yes - uses OGNL for type conversion with added converters provided for all basic types. |
| Custom Validations |
Yes |
Yes |
Yes |
| I18N |
Yes |
Yes |
Yes |
| Layout Support |
Yes - Tiles |
Yes - Tiles |
Yes - Velocity |
| IoC |
Yes (via managed beans) |
No |
Yes |
| XML configurability of Interceptors |
No (Listeners can act as Interceptors but there is no way to group more than one and specify the execution order via configuration file) |
No |
Yes (Interceptors can be grouped together and their ordering can be specified in the configuration file) |
| Popularity |
Gaining popularity rapidly. Even the beta release was quite popular considering the fact it was not even a stable release. |
Extremely popular |
Limited popularity |
| Maturity |
1.0 is quite stable but still there are and can be issues, but as this is supported by SUN and other big names these issues are surely to get resolved very soon. Ever growing community of it's users provide good support. Expected to be supported heavily by IDE Vendors. |
Highly stable and mature as there is a huge community of it's users and strong industry support. |
WW2 is stable and has matured but still there are issues and it takes time to get these fixed. Does not have strong Industry support and IDE vendor support. |
| Complexity |
JSF is supposed to be most complex to learn. It takes time to grasp the idea of components and event listeners but once you get familiar with this concept it's pretty simple. There are many books suppose to come out pretty soon. With the major thrust from SUN and other IDE vendors there will be soon number of tutorials and much study material available for JSF. |
Struts has a significant learning curve for developers new to web development. Adequate training is reuiqred to understand Struts. Changes to the framework which are sometimes major adds to this problem. A big relief is that there are a vast number of tutorials and books available on struts. |
Simple learning curve. Much easier than Struts or JSF but limited number of tutorials and books can create problems. |
| Future |
JSF will be the default industry standard for java based web applications. |
Will give way to JSF (as JSF becomes the standard). |
Uncertain |
|
|
Conclusion:
|
|
After evaluation of this framework it is no doubt that this is a much superior framework in comparison to Struts and WebWork. JSF addresses some of the key problems associated with development of web based applications. One of the key point in it's favor is that JSF is governed by JSR and will be part of the J2EE spec and hence will become the standard.
|
|
IDE vendors are coming up with support to JSF technology. In fact JSF is built to be IDE friendly that means we will soon have IDEs which will allow us to use JSF to build applications using drag n drop features for various components/objects.
|
|
With all this in process it is recommended that any application which is in initial stages of design/development should move to JSF. JSF is the way to build your next generation web applications using object oriented Component Model approach. For those who have applications built with struts there are libraries out already which can help them to migrate to JSF with least problems. Even if many struts addicts won't like it, it basically means leaving struts behind. Craig McClanahan (founder of struts and now specification lead for JSR-127) recommends transition from Struts to JSF rather than integrating the two and for new applications he recommends to use JSF as such.
|
|
With the way things are today it is certain that JSF will soon become the default industry standard for Java based web applications.
|
|
Recommendations:
|
|
If you have existing Struts-based applications that use the existing HTML tag library, you should do some experimenting and prototyping to determine the effort required to migrate your apps to the new JSF component architecture (the extra functionality you gain by doing this will be well worth the effort in many cases).
|
|
For applications now (or about to be) under development that have relatively short term schedules (i.e. the next few months), you should probably stick with the existing HTML library.
|
|
For applications with a longer lead time, seriously consider using JSF components instead of the Struts HTML tag library. Doing this will let you leverage not only the standard HTML components that come with JSF out of the box, but also the rich libraries of JSF components likely to be created by third parties in the future (including Struts developers).
|
|
Resources:
|
|
JavaServerFaces Java Specification Request (JSR-127)
|
|
http://www.jcp.org/en/jsr/detail?id=127
|
|
Sun's JavaServerFaces Page
|
|
http://java.sun.com/j2ee/javaserverfaces/
|
|
JavaServerFaces JavaDocs
|
|
http://java.sun.com/webservices/docs/1.2/api/
|
|
http://jsfcentral.com/
|
|
http://www.javaworld.com/javaworld/jw-11-2002/jw-1129-jsf_p.html
|
|
http://www.afceurope.com/JSF.html
|
|
http://www.theserverside.com/articles/printfriendly.tss?l=BestBothWorlds
|
|
http://www.onjava.com/lpt/a/4130
|
|
http://www.jamesholmes.com/JavaServerFaces/
|
|
http://www.jsfrepository.com/
|
|
http://www.jspolympus.com/JSF/JavaServerFaces.jsp
|
|
Information from Craig McClanahan (creator of Struts and spec lead for JSF) about Struts and JSF
|
|
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsMoreAboutJSF
|
