These days I analyzed the AJAX implementation of Mojarra. My goal was to learn enough about it to implement an improved version of the original AJAX implementation in our BootsFaces libraries. Along the way I learned that I had chosen quite a chunk to swallow. The JSF AJAX specification has many, many options, most of which I wasn’t even aware of. Time to write an exhaustive guide. Apart from the JSF specification we’ll also have a look at it’s PrimeFaces counterpart and – of course – what BootsFaces 0.8.0 will bring to you.
Why ordering matters
Every once in a while it’s important to control the order in which JSF libraries are loaded1. For instance, loading the LiferayFacesBridge 6.1 before PrimeFaces 5.x breaks the AJAX features of PrimeFaces. Both libraries replace the same Mojarra or MyFaces base class by their own, improved implementation. Unfortunately Liferay doesn’t cope with the implementation of PrimeFaces. Loading PrimeFaces first fixes the problem.
There are many more examples. JSF libraries such as OmniFaces, AngularFaces and BabbageFaces don’t provide widgets. Instead, they modify the way JSF requests are processed2. Those processors stack behind each other like a pipeline. It’s easy to imagine situations in which the reordering the pipeline makes a difference. For instance, it’s important that BabbageFaces is the last stage of the pipeline: it optimizes the HTML code generated by the previous stages.
This article shows how to modify the load order of JSF libraries.