BootsFaces 0.6.6, Easter Edition

Fork me on GitHubStop looking for our Easter egg: you’ve found it. The BootsFaces team celebrate Easter with a new version of their responsive JSF framework. By now, BootsFaces is available on Maven Central, and in a couple of days it’ll arrive on the jCenter repository.

Basically, BootsFaces 0.6.6 is a bug fix release. There are also a number of minor improvements, such as adding the style attribute to a number of components that ignored in in the previous version.

  • We’ve fixed the ordering of CSS and Javascript imports. Now it’s guaranteed that jQuery is loaded first, jQueryUI second, followed by the BootsFaces resource files. Everything else comes after that. This way developers can override any CSS setting of BootsFaces. You can also override Javascript definitions if you must (but proceed with care, since BootsFaces relies on its Javascript files).
  • We also rewrote the <b:selectOneMenu >. When I originally wrote the class, I designed it in a way that it hardly ever needs a custom converter. Unfortunately, I’d tested it with strings instead of objects when we published version 0.6.5, so things didn’t work quite the way I intended. Starting with version 0.6.6, you can really do without converters. That’s important because <b:selectOneMenu > doesn’t support converters yet. Nonetheless I intend to add converter support in one of the next versions, just for the case.
  • <b:tabView /> now is more resilient. It used to break when it found a comment where it expected a <b:tab />.
  • <b:commandButton /> now renders the title attribute as a tooltip. Plus, it respects the rendered attribute, and it renders the style attribute.
  • The same applies to <b:row />, <b:column /> and <b:container />. Now these components support both the style and the styleClass attribute.
  • In many cases you can now do without the UnmappedResourceHandler if you’re configuring the application correctly (see Issue #54 on GitHub). However, the GLYPHICONS still require either the UnmappedResourceHandler or the CombinedResourceHandler of OmniFaces. Until HTTP/2 becomes a wide-spread standard, it’s a good idea to use the CombinedResourceHandler in order to boost your application’s performance, so this issue isn’t our top priority.
  • Our new Font Awesome components didn’t work well if the Font Awesome CDN was blocked a firewall. BootsFaces 0.6.6 offers you a couple of solutions. If you want to suppress the automatical internet access for some reason, you’ve got several options. You can deactivate it globally in the web.xml, you can add a facet to the header of the JSF-view (which allows you to activate and deactivate the feature on a per-page basis), or you can simply include your own CSS import. If the file name contains the word font-awesome and ends with .css, BootsFaces won’t bother to load FontAwesome a second time. In most cases that’s precisely what you need to do anyways, so you don’t have to configure anything to deactivate the defaults.


Recently, the BootFaces project is gaining traction. The download figures are developing nicely (i.e. they’re rising), and there’s a lot of traffic on our issue tracker. This time I’d like give kudos to everyone who took the time and reported a bug or an enhancement proposal on our GitHub repository. It’s you who’re advancing the project!

Dig deeper

BootsFaces showcase and tutorial

6 thoughts on “BootsFaces 0.6.6, Easter Edition

    1. Do you refer to the menu of the showcase? That’s strange, because it works fine when I try it. Maybe it’s a problem specific to your browser? Is there a Javascript error message? Is Javascript deactivated on your machine, possibly by an ad blocker or privacy tool?

  1. 1.
    After clicking “BootsFaces” in the menu there is error:
    “NetworkError: 404 Not Found –
    After clicking “Getting Started”, “Layouts”, “Forms”, etc. in the menu there is no action at all. Only “Examples” works well.
    I compared with the page: – it works well.
    It happend just after BootsFaces 0.6.5 was released.
    I tested on FF, Chrome, Safari on a few available computers. It always works the same way.

      1. Another idea that might help: is there an error message in the Javascript error log? In case you’re not familiar with it: Hit the F12 key to open the web developer tools and open the “console” tab.
        It also could be a firewall problem (but that’s just a wild guess).

  2. The issue Michał Gnatowski describes turned out to be a localization problem with the datepicker component. It doesn’t occur on English, French, German, Portuguese or Brazilian browsers. Currently, we’re working on the issue.

Comments are closed.