While supporting the traditional AJAX style of JSF, BootsFaces also implements a new AJAX API that's a little simpler to use.
The BootsFaces AJAX API is supported by many, but not by all BootsFaces components. Currently, these components include:
<b:commandButton /><b:selectBooleanCheckbox /><b:selectOneMenu /><b:inputText /> and <b:inputSecret /><b:carousel /><b:panel /><b:tabView /><b:icon /><b:iconAwesome /><b:image />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.
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.
Use the process attribute to define which input fields are send to the server.
The attribute auto-update allows you to update a component on each AJAX request without explicitly mentioning it.
By default, you have to specify which parts of the DOM need to be updated. This can become tedious,
especially in the case of error messages. If an error occurs, you always want to inform your user.
Adding the attribute auto-update="true" does just that.
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.
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.
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.
onstart, oncomplete, onsuccess and onerrorStrictly speaking, there are four events that can be triggerd during an AJAX request:
onstart notifies your that an AJAX request is sent to the server.onerror is called when an exception happened on the server side.onsuccess is called when a request finished without exceptions.oncomplete is called when a request has finished, regardless of whether it was successful
or if an exception occurred.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:
update="@all" doesn't work in BootsFaces 0.8.0.update="@(body>*)") is very primitive. It fails if
there's a space in the jQuery expression.This demo shows some of the options at a glance.
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.