AJAX since 0.8.0

While supporting the traditional AJAX style of JSF, BootsFaces also implements a new AJAX API that's a little simpler to use.

State of the art

The BootsFaces AJAX API is supported by many, but not by all BootsFaces components. Currently, these components include:

Basic usage

The general idea is to use the JavaScript attributes for JSF AJAX calls. Unfortunately, JSF doesn't allow us to simply use the JSF EL syntax. So, we had to look for some inspiration, and we found it with an almost forgotten way to define HTML JavaScript callback handlers. You can optionally define such a handler by preceding it with javascript: to make clear which language you want to use. Similarly, BootsFaces uses the prefix ajax: to indicate the following code is Java code. If you want to execute another piece of JavaScript code after sending the AJAX call, prefix it with javascript: again. Notice that the second JavaScript code usually is executed before the Java code. AJAX means that the reference Java code is executed asynchronically.

Like said before, you can freely combine AJAX calls and JavaScript. If you want to execute JavaScript code after the AJAX call, you have to precede it with javascript:. Otherwise BootsFaces tries to run your JavaScript code on the server side.

You can also use more than one JavaScript attribute to call AJAX code: onclick, ondlbclick, onfocus, just to name a few. Each of these AJAX calls update the same part of the DOM tree, defined by the update attribute.

Partial processing

Use the process attribute to define which input fields are send to the server.

Advanced usage

Sometimes you need more flexibility. For instance, it's a common use case to update different regions, depending on the event. In this case you can resort to the traditional <f:ajax> facets of standard JSF. Note the diffenrent naming conventions: BootsFaces update becomes render, and process becomes execute. This is because f:ajax is provided by the underlying JSF framework, which doesn't follow the conventions of BootsFaces, which in turn has been inspired by (and is seeking compatibility to) PrimeFaces.

Exceptions during AJAX calls

For technical reasons, JSF reacts a bit ungraceful if the server raises an exception during and AJAX request. If you're using MyFaces and if you've configured your application to be in the development stage, you'll see a non-descript JavaScript error message. In every other case you don't see anything at all.

To solve the problem, register an AjaxExceptionHandler, as described at http://www.beyondjava.net/blog/jsf-2-0-hides-exceptions-ajax/. A good starting point is the OmniFaces FullAjaxExceptionHandler. If you use CDI and DeltaSpike, @ExceptionHandler is an interesting alternative.

(Virtually no) Limits to BootsFaces AJAX

From a technical point of view, you can do everything with BootsFaces AJAX - as long as the network latency permits. We've even been able to implement drag and drop via AJAX. This chess demo is an example of drag and drop using BootsFaces: BootsFaces Chess demo. You can move the chess pieces by clicking and draggging them to their target destination.

In other words: what you can and can not do with BootsFaces AJAX depends on your network latency (and your server-side processing time). BootsFaces processes AJAX fairly efficient, so it's unlikely BootsFaces is the bottleneck to your projects.

Known bugs and limitations

Live demo

This demo shows some of the options at a glance.

Which JSF framework do you like most?
What about JavaScript?
Which framework do you choose for desktop applications?
Last server-side events:
  • No message yet.
  • Play with the AJAXified widget to add messages.