This time, it took us half a year to publish a new release. But that doesn't mean we were lazy in the meantime. We didn't collect enough new features to justify a new version. Only - one day we realized we'd closed no less than 70 tickets since the last release. That's a whole lot of bugs solved!
Funny thing is that it took even more time to publish this article. I planned it for June 17, 2018. Now I have to hurry up in order to publish it before we publish BootsFaces 1.4, which should arrive any day soon.
Download coordinates
Before starting the long list of details, let me provide you with the download coordinates:
pom.xml:
A new breakpoint
Arguably the most interesting and most useful addition is the new breakpoint called XL. Truth to tell, it made it into the version because it slipped my attention. As much as I like the idea, my plans we much more ambitious. Now we've got a new breakpoint at a slightly odd size: 1400 pixels. We'll have to maintain it in the future, and it doesn't match the XL breakpoint of Bootstrap 4. I suppose we'll solve this problem by introducing a new breakpoint called XXL to BootsFaces 2.0.
Be that as it may, I'm pretty sure the new breakpoint comes in handy for everyone targeting desktop applications.
Sneak preview to BootsFaces 1.5: even more breakpoints?
My original plan was to introduce a whole bunch of new breakpoints, most of them specifically aimed at desktop computers. The range of breakpoints of Bootstrap always seems a bit odd to me, as I've complained about in April when I started experimenting with custom breakpoints. Mind you: the default breakpoints of Bootstrap are at 576px (Bootstrap 4 only), 768px, 992px, and 1200px. I've looked up the list of typical smartphone resolutions. IMHO, the Bootstrap breakpoints don't match these resolutions well. They suck at supporting laptops and desktop PCs.
Luckily, it's possible to add custom breakpoints to Bootstrap, and that's what I'd like to do in the next version of BootsFaces. Maybe we'll adopt some of the breakpoints of Material design. For instance, we could add a 1600px breakpoint, a full-HD breakpoint (1920px) and a 4K breakpoint. We could also add smaller breakpoints like the 1024px resolution, which is the (logical) resolution of the iPad and other tablets, such as the Nexus 9.
What's your opinion? Currently, I've deactivated the comment function of this blog because of the GDPR, but you can request a custom resolution on our poll in our bug tracker.
Filters in drop-down-boxes
Select2 is a nice community contribution by GitHub user Jottyfan. It allows you to filter the options of <b:selectOneMenu />.
When I started writing this article, I dived into the documentation of the component Jottyfan is using. Before long, I learned that there's more to discover. The underlying JavaScript component we're using to implement the new version of <b:selectOneMenu/> is surprisingly powerful and versatile. In a future version of BootsFaces, we may add the multiple choice feature (similar to Typeahead with tags). We also might add option groups. Stay tuned!
autoUpdate
Then the day came when we were asked "can you guys implement that cool autoUpdate feature of PrimeFaces?".
No. We won't do that. We're on good terms with the PrimeFaces team. Stealing features from their great framework sounds like a sure way to destroy that friendship. That's a no-go.
However, what we can do is to implement such a feature, adding significant added value along the way. The idea is to play with new ideas, bringing them back to the PrimeFaces world if they play out.
So that's what we did with the autoUpdate request. We couldn't improve the feature as such. You know, it's one of the simple but clever toys. Setting the attribute autoUpdate="true" on a <p:message /> causes this message to be automatically updated on every AJAX update, even if you don't add it to the update list. But I didn't see any reason to restrict this feature to messages. Instead, I implemented it for almost every visual BootsFaces component.
<b:openStreetMap />
OpenStreetMap is a nice widget contributed by our team member Matthew Broadhead. It allows you to include a map into your JSF application. All you have to know is the GPS coordinate of the center of the map, and, optionally, the GPS coordinates of a marker. The latter can even bear a simple popup message shown when the marker is clicked.
The nice thing about OpenStreetMap is that it's not only free, but also integrates with a wide range of services enriching your map with additional details. All you have to do is to add the URL pattern of the tile provider:
When I tried this demo again preparing this article, I ran into several CORS issues. You may need to configure your application server to allow the maps to be shown. Otherwise, modern browsers like Chrome tend to block the request.
<b:breadcrumbs />
Actually, we've already added this component in BootsFaces 1.2.1, but forgot to add a menu item in the showcase.
Basically, <b:breadcrumbs /> is simply a glorified list of links (i.e. <b:navLink />) plus some CSS. We've deliberately kept things simple because that's what Bootstrap recommends, and it gives you maximum flexibility to create your own fancy breadcrumbs by applying some CSS code.
Converters
We've improved the support for JSF converters a lot. Hopefully, now every bug is fixed, and the feature works as expected.
By the way, converter support used to be a bit weak in BootsFaces because I always avoid using them. My programming style often follows the "strings are easy" tradition. I like strong typing, but everything the user is inputting is either a mouse click or a sequence of keystrokes. In other words, the traditional data type to interact with the UI is the String, and that influenced my programming style. Be that as it may, BootsFaces finally supports using an object-oriented programming style in the UI layer.
@next and @previous
I always was at odds with the way @next and @previous work. You can use these selectors in an AJAX update or a for attribute. @next and @previos update the two items surrounding an input field. For example, you might add a validation constraint to an input field and verify it immediately as you type or then leaving the input field. If the validation rule is violated, both the label is colored red and the error message is show. For some reason, most developers are happy to do this with an id, but in my eyes a relative address like @next comes in handy.
Unfortunately, @next doesn't work accross a Bootstrap column (<b:col/>>). From the user's perspective, the message is next to the input field, but BootsFaces looks at the DOM and didn't recognize that.
We've fixed that in BootsFaces 1.3. Now you can use @previous and @next the way you intuitively want to use them.
Advanced masks on <b:inputText />
This is another community addition, this time by GitHub user @jepsar. He observed that the input masks we've introduced with BootsFaces 1.1.2 are much more versatile if we allow regular expressions. Plus, he found a simple way to pass such a regular expression without breaking backward compatibility:
jQuery
We've updated to jQuery 3.3.1.
We're also on track with getting rid of jQueryUI. There are only two components left requiring jQueryUI: the slider and the datepicker. Both widget have a decent replacement (<b:slider2/> and <b:dateTimePicker/>). So we'll remove the old components in one of the future versions of BootsFaces, allowing us to remove the jQueryUI library. You're still free to add jQueryUI yourself if you need it, but for most developers, jQueryUI has become a source of incompatibilities in the course of the last couple of years.
Minimum requirements (aka compatibility)
We've dropped support for Java 6. We've also made up our mind to drop support for a simple Tomcat or Jetty. Modern application servers have become almost as fast as Tomcat. I still like being able to carefully select and optimize the set of libraries I want to use in production, but in the age of Wildfly swarm and its friends, the all-in-one approach has become much more attractive than it used to be. In earlier times, most application servers ran a whole bunch of applications, making updating a shared library painful. Nowadays, there's usually a Docker container per application, so it's become a piece of cake to update your libraries.
Cutting a long story short: in future, we'll develop BootsFaces on application servers like Wildfly 14 and other application servers supporting JavaEE8 in general and JSF 2.3 in particular. BootsFaces should still run on older application servers, but they've stopped being our principal target.
Do you want to support us?
BootsFaces is a remarkable success story, and it continues with BootsFaces 1.3 and - very soon - BootsFaces 1.4. Nonetheless, the evolution of BootsFaces has slowed down considerably. In a way, that's a good sign: BootsFaces has reached a decent level of maturity. It's easy to add new components, but you developers have mostly stopped to request new components. Nowadays, most tickets in our bug tracker are bug reports. These bug reports become more and more convoluted. Many of these tickets remain unsolved simply because we don't know how to reproduce them.
On the other hand, BootsFaces is more popular than ever. We see 3.000 downloads from Maven Central each month, not counting the other distribution channels. That's where you come in. We appreciate any help from the community. Of course, we welcome code contributions (i.e., pull requests), but maybe it's even more fruitful to help us to reproduce the bug reports. Give it a try - it's a lot of fun to help other developers and to be part of a roaming developer community!
Wrapping it up
Everybody's telling me that JSF is a technology of the past. But even in the age of Angular, React.js, and Vue.js the BootsFaces project is still gaining more popularity by the month. It's the enthusiasm of the community that's driving us. So you can expect to see BootsFaces 1.4 soon, and we're already planning the version after that.