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.

Busy indicator

You can use the BlockUI feature to give feedback to the user. The general idea of BlockUI is to fade the screen to gray while an AJAX request is running. It also prevents the user from sending multiple AJAX requests. It's a common problem that hurried users start to click frantically because they simply don't know whether the application accepted the click or not. Giving the user visual feedback solves this problem. It also solves the dreaded "double click" problem. Many users have learned they need to use a double click to start an application, and it hardly ever causes problems, so they use it everywhere. Unfortunately, web applications don't work that way. They try to execute the action twice. BlockUI solves that problem, too. See the BlockUI page for more details.

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.

Corner cases: onstart, oncomplete, onsuccess and onerror

Strictly speaking, there are four events that can be triggerd during an AJAX request:

From a technical perspective, almost every AJAXified component of BootsFaces supports all events except onstart. Unfortunately, the API hasn't been unlocked for every component yet. Plus, none of the components support onstart yet.

You can circumvent this limitation by hooking directly into the JavaScript API of JSF:

IF you're using PrimeFaces, the API is slightly different:

Known bugs and limitations

Live demo

This demo shows some of the options at a glance.

Live preview

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.

Traditional JSF AJAX

By public demand, BootsFaces also supports the traditional approach to AJAX. But BootsFaces doesn't offer full compatibility. Most things work, but some features may be broken. That's because we put more resources on the BootsFaces syntax than on the legacy syntax.

Live preview

Which JSF framework do you like most?
Last server-side events:
  • No message yet.
  • Play with the AJAXified widget to add messages.