JSF and Ajax: ajax4jsf

Assuming that the component model of JSF is pretty well suited for Ajax applications, I found it surprisingly hard to find an Ajax framework that

  • has native support for JSF and the JSF lifecycle (unlike generic frameworks like AjaxAnywhere),
  • requires no custom Javascript coding for basic event/update mechanisms, and that
  • supports existing components unaware of Ajax.

There is a proof-of-concept implementation of a very JSF-centric approach proposed by Jacob Hokoom that fully utilizes the JSF component tree in the jsf-extensions project. Very promising, but it seems to be in a very early stage and requires JSF RI 1.2.

An existing alternative is Ajax4jsf, a rather mature and capable Ajax filter created and maintained by the Exadel people. Usage is fool-proof: using the a4j tag library, you either attach Ajax behavior to Javascript events (e.g. onchange) of existing input elements, or you add command buttons that emit Ajax calls when clicked, instead of reloading the whole page. When an Ajax event occurs, the form surrounding the element is submitted, making server-side handling identical to that of a common post-back. Ajax4jsf tags accept a list of component IDs to be re-rendered when the Ajax call was processed, automagically updating independent regions of the page. You don’t even have to identify those regions manually, for example, if a datatable should be updated – pass its ID to a4j and it will be updated when the server response arrives.

My only gripe so far is performance – by default, every request is routed through a Tidy filter, even for non-Ajax pages. This can be disabled by setting the forceparser init parameter to false (in the web.xml filter definition), which will only tidy up Ajax responses.

Oh, and if you’re using Facelets: read the docs ;). Remove the Facelets view handler from your faces-config.xml and set the org.ajax4jsf.VIEW_HANDLERS context parameter in the web.xml instead.

Besides possible performance concerns, I believe ajax4jsf’s interface is pretty much perfect for ajaxifying JSF applications without special needs – that is, wiring client-side events to JSF beans and rendering partial updates of a page. I’m all for simple, straight-forward solutions that just work – which is also the reason I was slightly disappointed of Pro JSF and Ajax with its clumsy (but surely more flexible) mabon. I guess I just don’t want to write more client-side Javascript than absolutely necessary for a pleasing user experience.

Advertisements

5 Comments »

  1. And as a client-side specialist I can add to this, that tidy filter on every request will mean murder to your CSS-based layouts. Tidy adds an xml-directive to the output of the page, which in turn prompt IE into stone-age rendering.

    Thanx for this page, it was my first hit on google when looking for the cause of tidy filtering in our current project and you hit the nerve, spot on 🙂

  2. Sonja Löhr said

    I just set “forceparse” to false, but nevertheless, everything is VERY slow since I installed the ajax4jsf filter (most of the requests still are non-ajax requests because of tomahawk components). The concept is great and it works fine, but the request-time now is unacceptable. Is there anything more one could do to speed things up?

  3. In my understanding setting “forceparse” to false should disable the tidy filter for all but Ajax requests. How do you set this parameter? My web.xml filter definition includes

    <filter>
    (…)
    <init-param>
    <param-name>forceparser</param-name>
    <param-value>false</param-value>
    </init-param>
    (…)
    </filter>

  4. […] at 12:01 am · Filed under AJAX, JavaScript, Java, Web Development, JSF While ajax4jsf is a very nice Ajax framework for JSF, it’s sometimes too expensive to submit an entire form and re-render […]

  5. Martin said

    You could try out the tomahawk-sandbox pprPanelGroup component. It does pretty much the same as ajax4jsf, but without the Tidy filter. This means that there are some restrictions in using it, though (e.g. you have to use JSF components in all partially updated page areas). We’re working on lifting this restrictions, too, but it will take some time.

    And you’re right AJAX4JSF is a dog performance wise!

    regards,

    Martin

RSS feed for comments on this post · TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: