Beyond Java

The BootsFaces team

First of all, I'm very proud to welcome two new team members. Both are very active and contributed quite a few improvements to our library. Welcome aboard, Dario D'Urzo and Philipp Gruhn!

Download coordinates

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

New version, new bugfixes, new bugs

BootsFaces 0.8.5 contains a lot of bug fixes. But we've introduced new features and did a lot of internal refactoring, so it wasn't too much of a surprise that the new version also contains new bugs. The only surprise was that the first new bug was reported before we've announced BootsFaces 0.8.5 in public. Until now, there's a workaround for the each bug reported. However, we're considering to publish a bugfix release prior to the next feature release (which isn't too far in the future itself). It depends on how many bugs the community reports, and if there are bugs without a workaround. You may wish to follow our bugtracker.

Compatibility to other frameworks

We've dropped formal support for AngularFaces. There's no reason why AngularFaces should not work with BootsFaces, but currently, we don't want to support AngularFaces officially. This will change when we'll publish AngularFaces 2.2, which is planned to be compatible to Angular2.

It goes without saying that both PrimeFaces and OmniFaces are first-class citizens of the BootsFaces domain. In fact, we're trying to align the API of BootsFaces with the API of PrimeFaces in order to minimize confusion. Unfortunately, many developers insist on using either PrimeFaces or BootsFaces exclusively. This leads to many duplicate components. But the general guideline still holds: if a component already exists in PrimeFaces, we won't add it to BootsFaces, unless we can add value to it. However, we don't object to pull requests. I still insist on the "extra value of PrimeFaces" principle, but at the end of the day, it's hard to refuse a gift.

Another JSF component framework that's on our watch list is ButterFaces. ButterFaces is a framework offering quite a few nifty components. Like BootsFaces, ButterFaces is based on Bootstrap. For some reason, they've managed to implement a set of components that are almost orthogonal to our components. In other words: ButterFaces is an ideal companion to BootsFaces. However, we didn't find enough spare time to finish our joint showcase, so we don't support ButterFaces officially yet. But we hope to be able to guarantee ButterFaces compatibility soon.

Every other JSF framework is either incompatible to BootsFaces, or it's not supported by us officially. In particular, ICEFaces is incompatible to BootsFaces. I'm told it's possible to use RichFaces along with BootsFaces, but it seems to be a painful affair. Oracle ADF is not supported at all. As far as I know, the basic concepts are just too different to even try.

Requirements: Java 6 and Tomcat

During development, we noticed that compatibility to Java 6 was broken. Nobody reported this yet, so maybe we should drop this requirement soon. However, we've fixed Java 6 compatibility with the current version.

Other than that, BootsFaces runs on a simple Tomcat or Jetty with both Apache MyFaces 2.2+ and Oracle Mojarra 2.2+.

Bug fixes

There are so many bug fixes I don't see a point to list them all. However, we've finally managed to solve one particularly nasty bug that forced us to use the CombinedResourceHandler of OmniFaces. That's no longer necessary. You can use the CombinedResourceHandler to improve the performance of your application, but now you can decide yourself whether you need it or not.

We've also solved a couple of annoying bugs of our new AJAX engine.

You can access the complete list of bug fixed in our release notes.

Eleven new components

Let's briefly summarize the new components. By the way, most of them have been contributed by Dario. He wrote no less than eight components. Awesome!

<b:growl /> is an alternative way to display FacesMessages. Basically, it's not that much different from it's PrimeFaces counterpart, but it follows the Bootstrap look and feel.

<b:focus /> directs the user input to a particular input field after navigating to another JSF page.

<b:accordion /> is a wrapper around several panel groups. The accordion component makes sure that at any give time, only one of the panels is expanded. The other panels are collapsed.

<b:defaultCommand /> is one of the components we've added by popular demand, although there's also a PrimeFaces counterpart. The defaultCommand component defines what happens if you submit a form by simply hitting the "enter" button. If there's more than one command button on your JSF page, <b:defaultCommand /> associates one of these buttons with the "enter" key.

<b:colorPicker /> is a, well, color picker component. There's nothing fancy about it, except that it offers more options to configure it than the standard HTML5 color picker.

<b:progressBar /> Another component that doesn't require a lot of explanation. The progress bar can be use to show the progress of a long-running task. As of BootsFaces 0.8.5, it doesn't refresh automatically. Instead, you have to update it yourself (e.g. using <b:poll />).

<b:scrollUp /> is useful on very long JSF pages. It allows you to scroll to the top with a single mouse click.

<b:scrollSpy /> allows you to highlight menu items when you scroll a page. If you're familiar with the Bootstrap website, you already know the idea: the sidebar menu always indicates which section of the page you're currently reading.

<b:tabLinks /> That's one of the components that were part of BootsFaces from the beginning, but which were never documented or maintained. Basically, the tabLinks component strongly resembles the <b:tabView /> component, but it's restricted to rendering the navigation row. This component may come in handy if you need more flexibility than the "worry-free" solution offers.

<b:pillLinks /> is more or less the same as <b:tabLinks />, but the default design is different. Instead of displaying tab the menu items are displayed as "pills" - i.e. they are surrounded by a box with rounded corners.

Experimental components

There are two components we consider production-ready, but we've marked as "experimental" in order to gain flexibility. In particular, we may decide to introduce breaking changes with the next version. It's unlikely, but it's a matter of politeness to warn you.

<b:tree /> is an AJAX-aware tree component based on the Bootstrap treeview with of Jonathan Miles.

<b:dataTable /> has matured a lot since 0.8.1. A surprisingly high number of pull requests show that it's a popular component, which is already used in production by some developers if I'm not mistaken. However, it still doesn't meet my expectations, so I've decided not to remove the "experimental" tag.

Easter eggs

Work on version 0.9.0 of BootsFaces has already begun, so BootsFaces 0.8.5 contains a couple of features we neither document nor support officially yet. But if you're the curious guy, you may have fun to look for the easter eggs :).

The new BootsFacesTagDecorator

When I developed AngularFaces, I noticed many AngularJS developers love to use the <div /> tag for many purposes. Unfortunately, the <div /> is not a first-class citizen of JSF. Trying to update a <div /> in an AJAX call is going to fail. So, I've create a JSF TagDecorator to convert the <div /> tag into a first-class citizen of JSF.

When I joined the BootsFaces project, I learned that Bootstrap web designers also love the <div /> tag. So it might be a good idea to make the <div /> tag a first class citizen of BootsFaces JSF. By the way, that's the only feature of BootsFaces requiring JSF 2.2.

Introducing a TagDecorator allows for a variety of new options. Converting <div /> tags to JSF tag is only the start. The BootsFaces BootsFacesTagDecorator allows you to drop the b: prefix in front of the BootsFaces tags. In my eyes, the result is much more easy to read. The drawback is that your IDE doesn't support the relaxed markup style. If you're using Netbeans, you're doomed: you simply can't use the relaxed style. Eclipse users can use the relaxed markup most of the time, except when they want to use the autocomplete feature of Eclipse. However, my recommendation is to activate autocompletion by temporarily adding the b: prefix, and removing it again later.

I'm going to dedicate an article to this feature on BeyondJava.net soon.

Improvements to existing components

• We've added flexibility to the icon of <b:navBar />. In particular, you can apply a CSS style specifically to the icon.
• <b:navLink /> and <b:navCommandLink /> can now be used as a solitary components. In that case, it's simply an AJAX-aware <h:link /> using the Bootstrap look and feel.
• We've started to add the "responsive attributes" (like span, visible, hidden, col-xx to every visible BootsFaces component. However, that's still work in progress. We expect this to be finished with BootsFaces 0.9.0.
• <b:message /> and <b:messages /> We've overhauled these two components. Now they are much more versatible and offer more components than ever.

Miscellaneous

I always found the standard way of generating error messages disturbingly cumbersome. Luckily, being a contributor to a JSF component framework, I'm able to do something about it. So I've introduced an alternative allowing you to notify users about error in a single line:

Actually, the FacesMessages class is already part of BootsFaces since version 0.8.1, but I didn't announce it earlier because I considered it experimental at the time. Later I discovered that OmniFaces already has a similar feature. Their class name is even shorter. It's simply Messages.

In spring a new version of Font Awesome was released, so we've updated BootsFaces to Font Awesome 4.6.1.

We've improved the documentation, in particular, the documentation of the attributes. We've also found and fixed a large number of bugs of the taglib file. In other words: now you can rely on your IDE's autocomplete feature. For instance, we've made the snake-case alternative to the standard camelCase attribute names available to every BootsFaces component and attribute. Putting it into simple words, you can now put hyphens at word boundaries. This style is popular among web developers, so it felt a bit odd to enforce the camelCase style only because it's the tradition of the Java language. Now you have both options. Choose the one that suits you.

Funny thing is, this feature has been reported as an error to us. Many attributes now are listed twice in the autocompletion list. That stirred some confusion on StackOverflow.

Philipp overhauled the AddResourcesListener. That's such a central class of BootsFaces this is worth a "Kudos" section of its own. Now the BootsFaces includes JavaScript and CSS resource files in a much more flexible and reliable way. You'd be surprised to learn in how many different ways people use our framework. BootsFaces has to support them all. Not too small a feat!

Internal refactoring

During the development of BootsFaces 0.8.5, we've conducted a lot of internal refactorings. First, we've optimized the Gradle build. Previously it could build only one theme at a time. That was fine as long as we only supported the default theme, but it became a lot of work when we added the 16 Bootswatch themes. It amounted to running the Gradle build 17 times during each release.

Second, the components now have a uniform package layout. This makes major refactorings or improvement easier. These kind of massive rebuilds are surprisingly frequent. Just think of adding the attribute visible to every visible component, which amounts to modifying 120 java classes, 60 documentation pages, and the taglib.

Adapting the ƒflow to 60+ components

Talking of which, managing more than sixty component is exhausting. You need powerful tools to make work easier. A couple of versions ago I've started to write an Xtext plugin to generate most of the boilerplate code of the JSF components. During the development of version 0.8.5, the plugin became much more powerful and versatile, chiefly in order to add cross-cutting features that affect many or even every BootsFaces component. Mind you: adding an attribute to a BootsFaces component means to modify four files: the JSF component itself, the renderer class, the taglib file and the documentation. The Xtext plugin can generate three of them. Taking into account that adding a feature like "responsiveness" amounts to adding not one, but seventeen attributes to each visible BootsFaces component, you can see how useful the plugin is. BeyondJava.net is going to dedicate an article to model driven development in general and to this plugin in particular soon.

Unfortunately, having everything generated by the Xtext plugin had undesired side effects. In former versions, the component classes and the taglib didn't always match each other. Nor did they match the DSL file. This was the reason of the bug that has been reported merely eight hours after releasing BootsFaces 0.8.5. Generating the component from scratch made a mistake visible that already lurked in the dark for a long time.

Migration path

In general, migrating from BootsFaces 0.8.1 to 0.8.5 should be as simple as modifying the Maven dependency. There's a potential breaking change with the AJAX engine. One of our demos broke because the AJAX engine couldn't update two adjacent DOM element simultaneously. We're still investigating the problem. The workaround is to wrap one of the DOM elements in an extra <div jsf:id="wrapperId" />. (Notice the jsf:id bit. It's necessary to make the element part of the JSF tree).

Kudos

Many developers have contributed to this version of BootsFaces. I can't stress this point enough: without your help, dear community, BootsFaces wasn't the success story it is today!

So, this time, our kudos go to every developer who reported a bug on GitHub or asked a question on Stackoverflow.com. I hope you don't mind to be listed individually. It would be a very long list. Thanks, folks!

Sneak Preview

As mentioned above, we've already started to work on many new features. Among other things, we want to add special support for your smartphone's sensors. The device you're carrying around all day has got so many useful sensors. Why don't you use them? BootsFaces is going to make this possible!

We've started to prepare a relaunch of our BootsFaces showcase. It's going to look much fresher and modern, and - more important - it's going to be much more useful.

Wrapping it up

Let me terminate this article with a personal statement. It just feels great to be part of such a vivid open source community. Many of you gave us valuable feedback. This led to a frightening stack of up to 80 open tickets in our bug tracker. At first glance, this is a bad thing. But in reality, it's not. It shows you are really interested in our software. Even better, in April we've seen 1750 downloads of BootsFaces from Maven Central, plus a couple of downloads from Bintray and - last not least! - our project homepage itself. Putting it all together, that's more than 2000 downloads in a single month. That's 2000 motivations to carry on our work!

Just in case you're interested in participating with this success story: you're invited to do so! It's easy: use our framework, write an article on your blog, tweet about it, talk about it on Facebook, report bugs you've found on or bug tracker. If you're the curious one, feel free to fix the bug yourself or contribute a feature you're missing yourself. It's as easy as forking our repository and sending us a pull request. As a reward, we'll mention you in the kudos section of the next "What's new in BootsFaces" article.

Cutting a long story short: the new version of BootsFaces has a lot in store for you, and there's even more to come.

Enjoy!

Dig deeper

BootsFaces project page

BootsFaces showcase (aka known as manual)

BootsFaces on GitHub

BootsFaces bugtracker

Sourcecode of the showcase

BootsFaces example projects