What’s New in BootsFaces 1.1.0?

Fork me on GitHubPutting it in a nutshell, the new version of BootsFaces doesn’t bring you new features. Instead, it focuses on quality and compliance with the HTML code recommended by the Bootstrap team. There’s only one new component, a few more concepts, but more than a hundred bug fixes. Granted, several of these bug fixes solve bugs introduced during the development of BootsFaces 1.1.0 itself, but even so, it’s an enormous progress. Since BootsFaces 1.0.2, we’ve committed to the core library more than 200 times, not to mention the commits to the showcase project. As it turns out, even a version introducing a single new component can be a major release.

Update May 02, 2017: Typo gremlin

Despite several weeks of testing, our good old friend, the typo gremlin, has sneaked into BootsFaces 1.1.0 again. This time, <b:form /> and the <b:growl /> are affected. We’ll publish version 1.1.1 soon, probably already this week-end.

Download coordinates

Before starting the long list of details, let me provide you with the download coordinates:

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


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

compile 'net.bootsfaces:bootsfaces:1.1.0'

The release page at GitHub offers several download options, such as the compact BootsFaces version featuring only the default theme.

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 https://github.com/TheCoder4eu/BootsFaces-OSP.

Breaking changes

It may sound a bit weird, but often fixing a bug amounts to introducing a breaking change. That happened during the development of BootsFaces 1.1.0 several times. Most of these breaking changes should be easy to fix. We’ve improved the grid system and the validation feedback. Earlier versions of BootsFaces generated HTML code that didn’t follow the rules of Bootstrap. However, it worked with a few minor glitches, so we’re sure there are projects out there relying on the faulty HTML code.

A breaking change we’ve introduced after the release candidate is the default value of the update attribute in AJAX requests. For some reason we’d set the default value to @form. That’s surprising because we’d already fixed the default value of the process attribute to make it compatible with standard JSF and PrimeFaces. As of BootsFaces 1.1.0, these are the default values:

BootsFaces 1.1.0 AJAX default values

Improved validation feedback

For some reason, we missed the built-in forms validation classes of Bootstrap when we’d implemented the input field several years ago. As a consequence, we created our own feedback CSS classes for coloring the label and the input field: bf-info, bf-warning, bf-error, bf-fatal, bf-no-message, bf-success, and bf-required.

Starting with BootsFaces 1.1.0, we generate the official HTML code recommended by the Bootstrap team. In other words, instead of adding a CSS class to both the field and the label, one of the CSS classes has-success, has-warning, or has-error is applied to the common parent element. As a side effect, error messages look nicer than with our original approach.

BootsFaces 1.1.0 now offers native Bootstrap validation

Compatibility settings for the validation

If you want to adopt BootsFaces 1.1.0, but don’t want to update your custom CSS rules, there’s a compatibility setting for you. Adding this context parameter to the web.xml will render the old HTML code:


This example also shows that you can use EL expressions in the web.xml for every context parameter defined by BootsFaces.

Horizontal vs. inline forms

The second major breaking change affects horizontal and inline forms. We didn’t implement a compatibility switch because the original HTML code was too different with the official Bootstrap code. Trying to keep the old HTML markup bears the risk of breaking when Bootstrap itself is updated. So we decided to re-implement the horizontal and inline forms from scratch.

If you’re using horizontal forms, you shouldn’t notice much of a difference. BootsFaces 1.0.2 and below generated code causing input field without margin. Chances are that you’ve fixed this by adding margins to input fields yourself. If so, you can drop this CSS rule after updating to BootsFaces 1.1.0.

Inline forms are a different story. Three diligent Bootstrap committers, Guillermo, Matthew, and Nicolalsotta, convinced me that there’s no such thing as a multi-line inline form. So we removed the code supporting multi-line inline forms. If you’re using inline forms, we recommend migrating to horizontal forms.

The new component of BootsFaces 1.1.0 adds more flexibility to horizontal forms. Bootstrap requires you to put every element of a row of a horizontal form into a form-group div. By default, BootsFaces adds this div automatically for you. However, if you want to add multiple elements to a row, such as a button behind the label and the input field, you need to wrap the elements manually in a <b:formGroup /> tag.


We’ve also started to update the showcase (once again). As the components of BootsFaces get more and more powerful, the documentation pages start to become long and confusing. Often adopters of BootsFaces report that it’s difficult to find a particular feature. We’ve started to improve the showcase, hoping to make it easier to use. However, that’s a lot of work. Currently, the showcase consists of 41.100 lines of JSF code.


Talking about statistics: the core library consists of roughly 75.000 lines of Java code. Currently, there are some 60 open issues, most of them proposals for new components and features. Since BootsFaces 1.0.2, we’ve closed (and solved) more than a hundred issues. During the last 12 months, 23 committers contributed to BootsFaces.

BootsFaces also continues to gain popularity. On average, there are 2.500 downloads from Maven Central each month. There are also quite a few downloads directly from the GitHub project page and other sources.

Disabling content of containers

That an improvement we started last autumn. Since BootsFaces 1.1.0, almost every container widget of BootsFaces supports the attribute content-disabled, allowing you to disable every input field within the container at once.

Getting rid of jQueryUI

We also reworked the experimental Bootstrap Slider (<b:slider2 />), which is going to replace the jQuery-UI based Slider. We think it is now sufficiently mature to use in your projects although there is still an issue preventing updating the value by a simple click on the slider rail. However, moving the handle by dragging it to the new position works. The Bootstrap Slider also lacks the responsive properties of its jQueryUI counterpart (<b:slider2 />). We hope to restore this feature in a future release.

Similarly, we consider the new <b:dateTimePicker /> mature enough to recommend to use it instead of the older <b:datePicker />. So BootsFaces now has good replacements for the two components based on jQueryUI. This, in turn, solves many problems developers reported. Some developers simply want to use as few libraries as possible. Other prefer to use their own version of jQueryUI. With BootsFaces 1.1.0, you’ve got the flexibility to do both.

Bug fixes and minor enhancements

There are countless minor bug fixes and enhancements. Worth noting is the data table, which becomes more and more complete, and the tree widget. Thanks to a Russian developer nicknamed PokImonZerg on GitHub, the tree component has become a lot faster and generates much less HTML code than before.

We’ve also been able to get rid of two bugs hunting us a long time. Now you can use BootsFaces both with and without the CombinedResourceHandler of OmniFaces. Until BootsFaces 1.0.2, the Glyphicons were not displayed if the optimized resource handler was activated. And you can use the BootsFaces command button in a JSF view with a <h:fileInputfile >. More generally speaking, the command button now works with multi-part forms (<b:form enctype="multipart/form-data">).

If you want to see the complete list of changes, have a look at the release notes or the bug tracker at our GitHub repository.


Many kudos go to Guillermo González de Agüero, Matthew Broadhead and GitHub user Nicalalsotta, who reported many bugs and contributed a lot of code. Guillermo started to overhaul the showcase, detecting many errors along the way. That’s also the reason why we’ve got more open issues than two weeks ago when we published the release candidate. Alexey Orekhov contributed several important improvements and bug fixes to the tree component. Ruan Felinsky helped us with useful bug reports, new ideas, and tests. Sergio Eduardo Dantas de Oliveira contributed the first version of the reworked validation feedback classes. I should also mention Jasper de Vries, GitHub users mtvweb, vdelacerda, LukaszCaputa, Wildfirefox, and Mihaly. Most likely I’ve forgotten to mention one or two others. Nonetheless, thanks a lot! Your contribution matters. It makes the life of several thousand BootsFaces users easier!

Wrapping it up

After three or four stability releases in a row, it’s time to look forward and to add new features. Depending on how fast Bootstrap 4 is release, we’ll concentrate either on migrating BootsFaces to Bootstrap 4 (that’d be BootsFaces 2.0) or on adding new features. We’re also discussing to raise the minimal requirements to JSF 2.2, Java 8, and JavaEE 7. If you want to participate with the discussion, leave a comment. We’d like to hear from you!

Dig deeper

BootsFaces project page
BootsFaces showcase (aka known as manual)
BootsFaces on GitHub
BootsFaces bugtracker
Sourcecode of the showcase
BootsFaces example projects
complete list of changes

3 thoughts on “What’s New in BootsFaces 1.1.0?

Leave a Reply

Your email address will not be published.