JavaServer Faces

What’s the JSF Framework hype?

In this section I try to tell the audience my experience in using JSF Framework and give some view points which I must say will be disagreed on by most of the other Software Architects, that’s life and that’s why it’s so interesting. In fact, even the expert group within JSF community did not agree on everything but they all had one vision for the JSF Specification, which is, to provide as much of decoupling between the presentation layer and the Java Servlet specification which is what JSP the most popular presentation layer solutions is dependent on. So let’s go on a ride.

Why do you need a framework?

There are many reasons but one compelling reason is if you adapt a framework then the framework forces every developer in a project to code in a certain way, which results in consistency across code. A huge benefit for software maintenance and operational phase in a SDLC. Another one is why reinvent the wheel and let the open source community do the hard part for us. It’s like saying I would rather go to a grocery story and buy a “fish” versus going in the cold out there for getting the great experience of doing real fishing (my apologies to the fishing group).

What JSF provides?

JSF is a Java standard that’s one benefit it provides over any other frameworks. What that means is all application servers will be required to provide support for this if they want to brag they are Java EE 5, 6 compliant. This also indirectly makes the development IDE provide support for JSF. So if you are not a guy who fights over whether “MAC” is better than “PC” or UNIX is better than Windows then I would suggest adapt this framework. In this section I will go about providing a summary of what I think JSF brings to the table. Thought out my web site I will never claim to know everything nor do I expect this website to be used as a reference for knowing every detail that’s associated with JSF. I would suggest buying some good books and I do not endorse any, in short you are on your own. I do encourage the readers to help me correct my mistakes and break my happy bubble that I know enough to write an article/blog on JSF. So let’s get into the guts of JSF

In order to understand JSF it’s important to get an idea about “JSF Request Processing Lifecycle”

Here is a brief summary for the lifecycle phases.

Restore View Restores or creates a server-side component tree (View) in memory to represent the UI information from a client.

Apply Request Values Updates these server-side components with fresh data from the client.
Process Validations Performs validation and data type conversion on the new data.

Update Model Values Updates any server-side Model objects with new data.

Invoke Application Invokes any application logic needed to fulfill the request and navigate to a new page if needed.

Render Response Renders a response to the requesting client.

A few topics that I refer to as “food for thought”

The JSF framework is all about component tree creation and UI components defined within the component tree. I think it’s an attempt to provide a class-object view of the html web page.

Back in the old days we used to create what I refer to as server side components. These components can then be used as server side controls which would be defined with custom tags. Both Java via custom tag controls and ASP.NET via UserControls provide us a way to create custom controls. In fact, ASP.NET provides so many out of the box server side controls. When this concept of server-side controls was first introduced I was a bit confused as in the earlier implementations web applications were all about client side scripting and even ASP and Servlet/JSP applications that I worked on where built with the idea “do as much scripting on client side” mentality. One reason for such push back in those days was due to internet bandwidth and what not, thinks have changed since then, although there are still parts of Vermont where we still have the old style “dial-up” phone access; we try to live in the cutting edge world.

Frameworks like JSF are providing this object representation on the server-side so that we can do the following

• Those UI components can then be defined in such a way that we can generate cross-browser scripts with configuration and not the old way of doing it which is to look at the server side for HTTP headers or at the client side with the correct DOM objects.


• By providing a component tree view, we can think of using templates (Facelets).


• We can do server side validations/conversion


• Create a Model-View-Controller pattern for decoupling each layer of the application.


• Remove the complexity of Servlet specifications from developers and have them concentrate on dealing with classes and objects.


• Since the UI components are managed in their corresponding classes, we can change the output that they render without impacting the application. In short they can be rendering output for other devices (example: PDA-WML) by just interacting with a different renderer class (JSF decouples the rendering aspect of a UI component, thereby allowing limitless possibilities)


• By creating component tree there is a possibility of view caching


• I can go on and on but I think you got the point

JSF has some features that ASP.NET also provides. I am not trying to imply that one is better than other or that there is a one-to-one correlation but I think some things do ring a bell in my mind. Note: ASP.NET is not a framework JSF is so there isn’t really an apple to apple comparison here. I just wanted to provide some pointers for my readers to think on. JSF provides a code-behind class via managed beans in the same way ASP.NET provides a code-behind class. ASP.NET can be compared more with JSP than with JSF as JSF provides more than what ASP.NET/JSP provides, it’s a framework remember, ASP.NET and JSP do not force any consistency across screen developments although defining good design patterns and following some clearly documented practices can minimize the spaghetti code across screens ASP.NET/JSP still leaves room for coding inconsistencies, some thing any framework tries to avoid (remember I said “tries”)

Let’s get into the nuts and bolts of JSF Framework

Managed Beans

Managed beans are defined in the “faces-config.xml” configuration file and serve as a code-behind class for the web pages using JSF UI components. Analogy wise, they are similar to ASP.NET code behind classes. These managed beans typically are used for the following reasons

• You can define member variables which are standard java data types and map them to the UI components in the web page this managed bean is tied to using the “Unified EL” (actually this is the new EL standard, earlier there was a fight between the expression language used for JSP, JSTL and JSF but now its unified hence the name “Unified EL”, lets not go there but if you are interested Google for “deferred” versus “immediate” expressions).


• You can define UI components (HtmlInputText, HtmlOutputText, HtmlCommandButton) as member variables, once you do that you get to play with the UI components methods and properties.


• You can define even listener methods within the managed beans, if you get lazy like me and use the managed beans for consuming events.

There are many more reasons for utilizing managed beans but you got the picture of where they fit in the puzzle called JSF framework.

Navigation Rules

The navigation rules are defined in the “faces-config.xml” configuration file and are typically used to provide a standard way of removing navigation hard-coding within code. This makes application navigation logic more of a configuration activity and less of changing the code. Now in the past we used to do it in one of the following ways

• Define it in database


• Define it in propriety xml file

But, now with JSF we can use well defined XSD schema which everyone is aware of as it’s now a part of the JSF specification; thereby minimizing headaches that occur when a staff member leaves the project leaving you stranded with your client expecting the project completion on a certain date.

The Navigation rules provide the decoupling just like any other framework; it has a list of possible navigation outcomes defined in the “faces-config.xml” configuration file and then it relies on the returned string from a class-method(referred to as an action class) to decide which outcome it should use for displaying the result. Typically the managed bean exposes a method which can do the determination or it could be any other class. Some times the navigation outcome is hard coded within the UI tag, example (“anchor” tag)

UI components

In short this is an object representation of the web page controls including the web page. The JSF framework creates a component tree which has pointers to the various UI components that are used by a JSF enabled web page. Note the UI components do not have to be utilized in the context of a web based browser application (we can use them in other applications like PDA). In fact the JSF framework provides complete decoupling between what application the UI component gets used in versus what needs to be rendered visually in that application. In short the rendering/viewing aspect is decoupled from the UI component thereby by allowing different renderers for the same UI component.

The UI component has various parts that work together to provide a truly scalable solution. The various parts are

• The UIComponent class


• The Renderer class


• The UIComponentTag class


• The Tag library description


• Associated helper classes

It’s possible to define different renderers which target different applications (web-browser based, PDA etc). You can also define the rendering within the UIComponent class and not use any Renderer class; a practice that I would not suggest you should follow when you define your own custom UI components. By defining the rendering within a separate class you can decouple the presentation schematics from the UIComponent thereby allowing you flexibility to change the renederer as well as change the presentation schematics without touching the UIComponent class. The “faces-config.xml” configuration is then used to tie the UIComponent to the various “Renderer” defined for the UIComponent

If you have done custom tag development using classic tags or the new “simple” tags then the use of “UIComponentTag” class and “Tag library” class shouldn’t be a learning curve.

The helper classes provide you with additional functionality (like Converters, Validators, ActionListeners) to the UI Components and can be attached to the UI component either programmatically or via the tag attributes.

Event Model

The JavaServer Faces event model differs from most other Web development technologies because it provides an event-based programming model that is similar to the one used in traditional, thick-client development with Swing or AWT. Which is why in my opinion they have to create View tree of components since then we can deal with events.

The events/listeners can be of the following types

• FacesEvent / FacesListener
• PhaseEvent / PhaseListener

The FacesEvent / FacesListener combination can be used to deal with events that occur at the UI component level.

The PhaseEvent / PhaseListener combination can be used to tap into the “JSF Request Processing Lifecycle”

The JSF framework allows creation of custom events and listeners for UI components. Basically, once again providing what a mature framework should provide which is an ability to extend the framework to suite your project needs; in this case define events and listeners to suite your needs.

Conversion and Validation

Converters are instances of javax.faces.convert.Converter class, and validators are instances of javax.faces.validator.Validator class. Conversion (from String to Object, as everything in the http world is “String”) and Validation normally happen during the Process Validations phase of the request processing lifecycle of JSF framework (unless the component has its immediate property set to true, in which case they happen during the Apply Request Values phase). Conversion (from Object to String, as the output for rendering is mostly “String”) happens during the Render Response phase of the request processing lifecycle. Conversion happens first and then Validation.

Besides providing many out of the box converters and validators the JSF framework keeping with the philosophy of configurability and extendibility, allows you to create custom Converters as well as custom Validators.

AJAX/Custom UI components

JSF framework allows you to create custom UI components. In order for you to create a custom UI component you will have to define custom versions representing each of the following parts

• The UIComponent class


• The Renderer class


• The UIComponentTag class


• The Tag library description


• Associated helper classes

JSF framework provides you base classes for each of the parts which you can extend and customize. For example, you can extend the UIComponentBase for creating a custom UI component part. You can extend the UIComponentTag class for creating the custom UI tag.

The rendering of the UI component can be defined within the UI component class which is extending the base class (UIComponentBase). However, I would not recommend doing that. I would rather see developers defining a separate rendering class that extends the Renderer base class. This provides a decoupling between the UI component and the rendering of the UI component.

Each base class provided by the JSF framework provides some basic functionality exposed via member variables, events, and methods to integrate the custom UI component with the “JSF Request Processing Lifecycle”.

If you want to use the UI component in the context of AJAX (Asynchronous JavaScript and XML) all you need concentrate on is the following

• The UI component or their renderers can either generate an inline JavaScript code when it gets rendered on the web page or make call to a JavaScript function defined in an external JavaScript library which in turn will utilize the XMLHTTPRequest API or some form of JavaScript library functions which will make the RPC calls to the server component.


• The server component could be another JSF UI component or a servlet which can return either an XML or JSON (JavaScript Object Notation) which ever you like. You can then use standard JavaScript techniques to refresh data on the web page without submitting the entire page (“vola” – AJAX)

JSF 2.0 framework provides some out of the box AJAX JSF UI components so if you have patience for the final specification to be out just wait for that to occur.

NOTE:

Back in the good old days we used to make RPC calls over the HTTP and TCP/IP protocol (in fact this technique dated as far back as the mainframe “green-screen” world) and I never knew that they would come up with fancy buzz works like AJAX, Web 2.0 and RIA (Rich Internet Application). I never thought in my wildest dreams that there would be so many JavaScript libraries and RIA frameworks out there which all at their very heart would rely on RPC calls using the XMLHTTPRequest object.

What’s inside the “faces-config.xml” file?

• Navigation rules
• Managed beans
• Custom Converters
• Custom Validators
• Phase Listeners
• Renderers
• Resource Bundle for language support
• Custom ViewHandler
• Custom ActionListener

What’s new in JSF 2.0?

• Built in templating with Facelets
• Full support for Ajax, as easy as adding one tag
• Easy component creation, as easy as building a Facelets page
• OO component model maximizes maintainability
• Great support for building internationalized and accessible applications
• “Pay as you go” complexity tax: features you don't need don't get in the way
• Highly secure, with built in protection from cross site scripting, CSRF, and other kinds of attacks
• Java EE standard guarantees the safety of your IT investment
• Comes with every Application Server, giving you a large pool of developer talent, training, and books in many languages.