Addy is in software development at UBS working on ETD trade management systems. He has previously worked in technical consultancy for 10 years and have enjoyed working with clients/verticals ranging from media, hospitality, energy to finance. In his spare time he loves trying out new Java based technologies especially open source frameworks like Apache and Spring. Aditya has posted 4 posts at DZone. You can read more from them at their website. View Full User Profile

A Few Considerations While Selecting JSF-based AJAX Libraries

  • submit to reddit

The demand for AJAX based web applications has been a trend for some time now. To support this trend there are bunch of options available in the market right now. To keep the scope of this post limited, I'll be talking specifically about JSF component libraries which provide AJAX support. 

There are quite a few AJAX enabled JSF component libraries available in the market and some of the most popular ones are RichFaces, ICEfaces, and Oracles's ADF. We recently used Rich Faces in one of our projects and as always, there were some challenges and lessons we learnt. I have tried to extract a few of those lessons that everyone else can benefit from while selecting JSF component libraries especially for AJAX behaviour.

Considerations while choosing JSF component libraries and developing AJAX web applications:

  • Rendering performance of the AJAX libraries - This is particularly important if you have a lot of AJAX functionality on one page. For example with growing data tables and additional AJAX behaviours like tooltips and suggestions, performance of a page can degrade. In our case, Rich Faces was spitting out a lot of javascript code for every element that needed tooltip degrading client-side rendering. Also, it uses HTML parsers on server side which again creates a performance overhead.
  • Handling of simultaneous asynchronous events – If you are dealing with a lot of asynchronous events being generated, sequence in which the events are processed at the server side can be very important. For example, “onkeyup” event generates events as you type, and if you do not have any mechanism in place to handle simultaneous AJAX events, state on your server side can go out of synch with the state on client side. Some libraries like Rich Faces provide queuing to manage AJAX request traffic.
  • Essential extension points – There will always be some extensions you would want to do whether it is to overcome the shortcomings of the libraries or to add some business functionality. Hence, most libraries provide essential extension points which are “pre” and “post” all AJAX events are fired and a particular AJAX event is fired.
  • Interoperability – This might not be high on the list if a toolkit provides you everything that you need. But if you have to use the libraries alongside other libraries, then interoperability issues can lead to serious trouble. For example, in Rich Faces uses servlet filters to inject itself in the processing sequence which is known to cause some interoperability issues with Tomahawk file upload features
  • Strategy for tabbing – This is one of the areas which we initially thought was a no brainer but eventually became a nightmare. Tabbing through the input fields improves the usability of the web-page a lot whether it is an internal app or public facing, especially, if the webpage has quite a few input components. JSF tags provide tabindex attribute which are provided in AJAX component libraries as well. But pages where AJAX events cause show and hide of new fields, “tabindex” attribute is worthless. Also, hard-coding tabindex value can cause headaches when you want to introduce new fields in a page which invalidate existing tab indices.
  • Debugging of AJAX components - As a lot goes on behind the scenes before an AJAX request is handled on client side and after AJAX response in received on client side. Hence, if you get unexpected results debugging facilities provided the libraries can be very useful. Rich Faces provides a “log” tag which can be tuned with log levels to show information.
  • Templating of component (JSF 2) - This is another important aspect to look out for if your UI designs are not flexible. Templated components will allow developers to change existing component provided by a libraries to fit their needs.
  • Finally, good documentation with working examples can accelerate the development process. I found Rich Faces live demo web site quite useful as it lets you play around with different working examples so you can decide which design to use before you start coding it.

From :

Published at DZone with permission of its author, Aditya Bhardwaj.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Rigel Kentaurus replied on Tue, 2009/09/15 - 9:20am

I have found the ready-to-use components to be pretty lacking and if interesting, really frustrating for a real world application, not that they are not useful, they can help me fire a really quick AJAX application in a few minutes, but I really think they constraint usability and originality.

The first generation of those frameworks came to the extent of sending the whole request to the server, parsing the whole JSF cycle, and then returning a part of the page so the client can re-render that part. That wasn't too far away from an actual full page load and instead of the lean 1 parameter request, 1 json object AJAX call, I had a full HTML request with a bunch of paremeters (AND a viewstate), and a full HTML response. Far, far away from what I would call network performance. I understand that both Icefaces and RichFaces have been improving in this area.

Also, I had a lot of trouble when rendering really basic scenarios, consider this:

A select list, when a value is selected, another part of the form renders.
When something in the form is selected, a list of checkboxes is shown
When a checkbox is marked, an other part of the form is rendered

It turned out that we ended in a lot of weird scenarios of the form not being submitted, the values didn't ending in the model bean, and other weird errors. This was with Ajax4JSF. We ended up not using AJAX at all because debugging was real hell. when we finally got it at the point of almost working, a weird error crawled again

I wouldn't rule out AJAX frameworks, for a quick suggestions input box, or a full featured ajax datatable, I'm all in. But I don't think I'll be using it for every AJAX interaction in my page, an extra framework like YUI and some coding done in javascript is much more cleaner, and gives a lot more performance ... as long as one doesn't get in the middle of the JSF processing cycle (for example, I cannot add a few inputs and expect them to be known by JSF), but at some projects I have actually ditched JSF altogether in benefit of some richer JS libraries.

Andrew Arrigoni replied on Tue, 2009/09/15 - 10:20am

Good summary of some things to look out for. AJAX libraries are good for what they're there for: Giving you ready-to-use widgets out of the box. Sure, you can expand that but after a while, you move away from the sweet spot of RichFaces and would end up doing better by making your own components. Hopefully in JSF 2, that will be easier but even Facelets would give you plenty to work with.

Fortunately or unfortunately, depending on your point of view, these AJAX frameworks have a good sweet spot. I know I've managed to get IceFaces to do things that are outside its sweet spot. I have dozens of places where all I'm doing is hiding and unhiding a portion of the page. This would be better handled through a new component than the server-side state that I have it built on now. 

 AJAX for JSF might be a better choice but I haven't used it much.

The beauty of JSF is its component nature. If the existing components don't work, you can make your own. Don't be afraid to do this. It's not as hard as it seems.

Max Katz replied on Tue, 2009/09/15 - 2:28pm

RichFaces parser can be turned off or configured only for particular pages.


Aditya Bhardwaj replied on Wed, 2009/09/16 - 7:51am

We developed our application with JSF and RichFaces which is in production since last 6 months (it is our client's internal application). We did experience limitations in terms of changing the layouts of the components which is a problem with JSF 1.x as a whole. But as our requirements were flexible from UI design perspective our designs revolved around what was already provided by Rich Faces and JSF.

Also, we had lots of pages where we had to to hide and show dropdowns, checkboxes input fields, modals, etc and I can't remember having any issues with those. There was a learning curve initially to understand how things work but it went smoothly after that. 

One great thing about JSF 2 I am looking forward to is the templating of components. This will improve on the limitation on UI of the component as it can be customizable as long general behaviour of the component remain the same. I will add that as another point in the blog to check for in libraries. 

And, yes to add on to Max's response, you can configure RichFaces not to use parsers but then AJAX stops working and there are no logs to tell you which part is failing. We ended up using NEKO parser which is better of the 2 options available in Rich Faces. I am still keep to explore why the app doesn't work without parsers. It must be something we are missing in our views but some kind of logging would be nice.

Sudhakar Ramasamy replied on Wed, 2009/09/30 - 12:54pm

We are using RichFaces with JSF 1.2 and facelets (for templating) with reasonable success for over a year. The one hiccup we ran into was RichFaces bundles jQuery and proptotype and that messes with the version of jQuery we include ourselves. But nothing that has been a show stopper so far.

Aditya Bhardwaj replied on Fri, 2009/10/02 - 11:37am

Yes, we had the same issue and we ended up using rich faces version of jQuery.

Cagatay Civici replied on Fri, 2009/10/09 - 7:07pm

I'd like to include PrimeFaces which satisfies almost all of the requirements mentioned. PrimeFaces is based on the principle which states that a good UI component should hide complexity while keeping flexibility. Additionally PrimeFaces ajax has no Html parser, servlet filter, custom view handler, custom statemanager, partial triggers, copy of dom tree on server and etc. There's only one phaselistener handling the ajax events and making PrimeFaces lighter compared to other libraries. Interoperability is another goal of PrimeFaces, you can even control which resources are included in the page.

Aditya Bhardwaj replied on Mon, 2009/10/19 - 8:31am in response to: Cagatay Civici

Thanks Cagatay. I was quite impressed with the session we had on PrimeFaces though I am yet to try it out for real. Couple of my colleagues did try PrimeFaces is a Proof of concept and found it quite easy to use as compared to RichFaces. The only aspect I wasn't able to verify is how PrimeFaces manages queues and the sequencing of the AJAX request.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.