Category Archives: AJAX

What’s New in BootsFaces 0.8.1?

The open source branch of BootsFaces is still young. Only 14 months went by since the first release on Halloween 2014. But it’s already an impressive success story. In November, we’ve seen more than 1.000 downloads from Maven Central and Bintray. Ed Burns mentioned BootsFaces in one of his talks at JavaOne. JSFCentral and have asked us to write articles about BootsFaces. Obviously, BootsFaces has stirred a lot of attention, and many projects use it for their daily work.

Since the Halloween 2014 release, we’ve published five releases. That’s roughly a release every three months. The latest release took quite bit longer to finish. But it’s loaded with a host of new features, so it has surely been worth the wait. Personally, I call it the AJAX release, because that’s my big ticket. But there’s more in store four you. Other big tickets are the advanced search expressions inspired by PrimeFaces and the theme support. Plus, BootsFaces 0.8.1 has six new components. Seven, if you count the experimental <b:dataTable />. But that not a finished component yet. However, I felt it already is useful enough to include it with BootsFaces, even if it still requires polishing and “sugaring”.

But let’s talk about first things first.

Download coordinates

BootsFaces is available in two different flavors. There’s the regular version at Maven Central, and there’s a highly-optimized version at GitHub. The optimized version is 50 KB smaller, requires Java 7 or higher and should be a bit faster. The version hosted a Maven Central is targeted at a broader audience. It only requires Java 6. Alternatively, you can check out the repository from GitHub and build BootsFaces from source.

Add these lines to your project’s pom.xml:


Add this line to your project’s .gradle build file:

runtime 'net.bootsfaces:bootsfaces:0.8.1'

The BootsFaces project comes with both a Gradle build file and a Maven build file. The Maven pom.xml is the easy way to get started and should suffice for most purposes. Only if you want to tweak and optimize BootsFaces, you need the Gradle build. In particular, the Maven build doesn’t generate the CSS and JS files itself, but relies on the output of the Gradle build. By the way, that’s the reason why we keep the generated file in GitHub.

In any case, the URL of the repository is

Continue reading

A Comprehensive Guide to JSF AJAX

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.

Source code of the examples

You can find the source code of the examples on GitHub. There’s a second project on GitHub covering the BootsFaces AJAX examples.
Continue reading

Single-Page Applications With BootsFaces

Singe-page applications have become tremendously popular in the last couple of years. They are fast, they are responsive and they can save network bandwidth. The first SPAs that caught the attention of the community were based on JavaScript. So nowadays everybody seems to believe you can’t write an SPA with JSF.

But you can. It’s not even difficult. And it pays: the application becomes much more responsive. This article shows two approaches how to do it with BootsFaces. I’m sure you can do the same with other JSF frameworks like PrimeFaces, too, but I didn’t test it yet.

Currently, there are at least two approaches. You can exploit BootsFaces AJAX to do your navigation, or you can add AngularJS to the equation. The latter approach requires you to learn both Angular and JSF, but it may be useful because it allows you to use client-side AngularJS components.
Continue reading

An Alternative API to JSF AJAX

As BootsFaces gains traction, people start to ask for AJAX capabilities. We’ve implemented some rudimentary AJAX support, but obviously that’s not enough. Developers need the full power of JSF 2.2 AJAX.

Funny thing is they demand it precisely the way JSF 2.0 defines it. It was a really clever approach when it was introduced. But I think in 2015 we can do better. I was always puzzled by the slightly counter-intuitive approach of JSF AJAX. Why do we have to use a facet to activate AJAX? Why do we need so many ids? And what does the attribute name execute mean, for that matter? For execute doesn’t execute anything. Instead, it defines which data to send.

The tradional JSF approach to AJAX

   <h:inputText id="name" value="#{}">
   <h:commandButton value="Welcome Me">
      <f:ajax execute="name" render="output" />
   <h:outputText id="output" value="#{helloBean.sayWelcome}" />	

The PrimeFaces approach

PrimeFaces shows us how to do thing better and more concise. Actually, AJAX and the superior search expressions are the two top reasons why I’m so fond of PrimeFaces. PrimeFaces allows for a very compact definition of AJAXified command buttons:

   <h:inputText value="#{}" />
   <p:commandButton value="Welcome Me" 
                    process="@previous" update="@next" >
   <h:outputText value="#{helloBean.sayWelcome}" />

We’ve got rid of the facet, we’ve got a powerful expression language allowing us to get rid of the ids and we’ve got much more intuitive keywords to define which inputs fields to send and which region of the DOM is to be updated.

Unfortunately, even PrimeFaces uses verbose event facets for almost every other AJAX event:

<p:inputText value="#{userBean.firstname}">
     <p:ajax event="keyup" 
             update="@next" listener="#{userBean.onKeyUp}"  />
<h:outputText value="#{userBean.firstname}" />
<p:inputText value="#{userBean.lastname}">
     <p:ajax event="blur" 
             update="@next" listener="#{userBean.onBlur}"   />
<h:outputText value="#{userView.lastname}"/>

The BootsFaces approach: a proposal

Now, let’s go one step further. Most interactive BootsFaces components already have quite a few JavaScript callbacks: onclick, onchange, onblur and so on. Why don’t we use precisely these callback attributes to define AJAX behaviour?

<b:inputText value="#{userBean.firstname}" 
             onkeyup="#{userBean.onKeyUp}" update="@next" />
<b:outputText value="#{userBean.firstname}" />

<b:inputText value="#{userBean.lastname}" 
             onblur="#{userBean.onBlur}" update="@next" />
<b:outputText value="#{userView.lastname}"/>

Note there’s a double use of the JavaScript callbacks. The general idea is to act differently according to the type of the onblur and onkeyup methods. If it evaluates to a string, it’s a Javascript method. If it evaluates to a method, it’s a JSF method.

This way, you’ve got a simple, intuitive API allowing for very concise code. Using the callbacks you even veto (i.e. prevent) the default action from taking place – a feature that’s lacking in the JSF world for some reason, but has always been possible in the Javascript world by simply returning false.

Update April 9, 2016

In the meantime I’ve implemented my proposal. Now it’s part of the current BootsFaces releases. But my proposal didn’t make it into the productive code without changes. Using the EL syntax for JSF calls is a nice idea, but it simply doesn’t work. For one, this approach would prevent you from defining the JavaScript code in the bean. No matter how unusual this use case may seem: it’s a valid use case, so BootsFaces should support it. Second, there’s simply no way to distinguish between a simple string and an EL expression. So I’ve decided to modify the syntax of my proposal. In the early days, developers used to prefix their JavaScript code with “javascript:”. So why don’t we follow this tradition and prefix our AJAX code with “ajax:”? Hence, the current syntax looks like so:

<b:inputText value="#{userBean.firstname}" 
             onkeyup="console.log('before the AJAX call');
                      javascript:console.log('after the AJAX call');" 
                      update="@next" />

Note that the second log is called after submitting the AJAX request, but it is executed almost always before the AJAX response is processed. That’s the nature of AJAX: it’s asynchronous.

What about you?

If the majority of you, dear readers, doesn’t feel comfortable with the double use of the callback methods, we could also introduce additional callback methods. For instance, we could call the callback methods onClickJava, onBlurJava, onChangeJava, onDragStartJava and onDropJava. Personally, I don’t think that’s necessary, but it’s you who count, so I’d like to hear from you. How do you like the idea? Which implementation would you like to see in implementation? Do you prefer the standard JSF way using event facets? If so, why? Or why not, for that matter?