Category Archives: JSF

What’s New in BootsFaces 1.0?

BootsFaces 1.0 has been released. Actually, we’ve already published the first bugfix release, BootsFaces 1.0.1. I was a bit shy to proudly announce the 1.0.0 version because we had so many obstacles to overcome. Apart from the usual obstacles like exhausting projects at work (and they were exhausting this time!), there were also the earthquakes in Italy, which kept at least one of our team members busy, although they didn’t suffer any physical harm.

Be that as it may, BootsFaces 1.0 (and 1.0.1 in particular) is a great step to maturity. It’s the first version we officially call “production-ready”. Truth to tell, we were always convinced you can safely use BootsFaces in production. But most versions we’ve published in the past focused on features. This time we tried to focus on stability instead of new features when we prepared the 1.0 version. I counted 26 bugfixes that were important enough to open a bug ticket. Plus, almost twenty minor enhancements and three new components. However, we also added one or two major improvements, such as adding support for both horizontal and inline forms.

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:

<dependency>
    <groupId>net.bootsfaces</groupId>
    <artifactId>bootsfaces</artifactId>
    <version>1.0.1</version>
    <scope>compile</scope>
</dependency>

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

compile 'net.bootsfaces:bootsfaces:1.0.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 https://github.com/TheCoder4eu/BootsFaces-OSP.

Update Dec 27, 2016: Bugs

During the last couple of days, we’ve found and fixed a couple of bugs. If you happen to run into a bug, check our bug tracker if we’ve already solved the bug, and check out the sneak preview version of BootsFaces 1.1.0-SNAPSHOT. Strictly speaking, this version is not intended to use productively. Use at own risk. Of course, BootsFaces is published under an Apache V2 license, so every version of BootsFaces is published on an “as-is” basis, without any warranties. The difference between the snapshot and the final version is that we’ve tested the final version more intensively.

Continue reading

Java UIs: State of JavaServer Faces (JSF) in 2016

How to update a popular article that made it to rank 2 on the Google search results? My survey article about Java UIs is three years old, so it clearly needs an update. Instead of rewriting I decided to write a series of short articles each covering a single UI framework. I’ll concentrate on the JavaScript and Java world. On my list are MVC 1.0 (aka Ozark), Angular2, D3.js (even it’s not a general-purpose framework), JavaFX and many others. Maybe I’ll also add an excursion to the Microsoft world. For instance, UWP / Xamarin is an interesting UI framework I’d like to cover.

JSF

But let’s start with the framework I know better than most: JSF. As you may or may not know, I’m a contributor to a JSF component library, so you’ll get first-hand information. It goes without saying that it may be a bit biased. That’s the drawback of getting first-hand information. By the way, if you’re interested in a quick summary, you can jump directly to the State of the art (2016) paragraph.

JSF – why should I care?

Don’t be fooled by what you read in the forums. Many developers speak ill of JSF and call it a dead horse. But JSF is still alive and kicking in 2016, especially in Europe and Brazil. Like so many other things in the information science space, JSF frequently becomes a victim of flame wars. There are so many critics of JSF I decided to address them first before explaining what JSF is. Feel free to skip this paragraph if you’re not biased against JSF.

Putting it in a nutshell, there are two sources of criticism. First, the 1.x versions of JSF were really bad. (At least I’m told so, I never used it). But the designers of JSF have learnt their lesson and corrected many design flaws of JSF 1.x. Version 2.0 was a big step forward, and subsequent versions became even better. If you’ve suffered from version 1.x and ran away crying, let me tell you that using a current JSF version is fun.

Second, JSF is an old, even outdated technology. Old by the definition of computer science: it’s still useful, and it still evolves, but you simply don’t need it anymore. Ten or fifteen years ago, it was a good idea to render HTML code on the server side. Simply because there was no other option. HTML and JavaScript programmers had to keep the difference between the browsers in mind, JavaScript was slow and far from being a useful standard, and you couldn’t write UI components. Nowadays, browsers have evolved a lot. There are so many useful UI components in the JavaScript world that it seems ridiculous to generate them on the server side. Even worse, powerful JSF components tend to generate a lot of code, which results in long page load times. Processing input on the server feels like a bad idea, too. It means a lot of network traffic. More often than not, the result is an application that doesn’t feel responsive.

However, that’s only one side of the coin. Under certain circumstances, JSF still has its advantages. For instance, it puts less drain on your cellphone’s battery, and it runs smoothly on old or cheap clients (if optimized accordingly). You know, most readers of this blog live in the United States or Europe, where it’s fairly common to own both a powerful smartphone and access to fast internet, but there are many countries in the world that are far less privileged. In fact, there are many people in your country that can hardly afford internet access. According to this speech, minimum wage workers in India need to work one hour just to access 15 web pages. Even in Germany, minimum wage workers have to work a couple of hours just to achieve the cheapest possible access to the internet. From this perspective, it makes a lot of sense to keep both web sites small and the CPU requirements low. JSF can do this much more efficiently than most applications based on JavaScript. It goes without saying that most JSF applications aren’t optimized for low CPU usage and low network traffic. All I say is if you need to optimize, JSF may become very attractive.

Be that as it may, JSF is still very popular in a variety of countries, in particular in Brazil and in Europe.

I’d like to add a third point. I often feel JSF is annoyingly clumsy. I suspect many developers shy away from JSF because the feel the same. That’s why I contribute to BootsFaces. This framework is dedicated to making a developer’s life simpler.

What is JSF?

JSF is a server-side web-application framework trying to abstract from the peculiarities of the browser. Strictly, speaking, it’s even wrong to say JSF is a web framework. The web is only the most popular target platform. There’s at least one JSF implementation running on JavaFX: Captain Casa. I don’t know about their market share, but the company exists since 2007, and they seem to have found their stable niche. It’s definitely an interesting approach to writing desktop applications.

However, the vast majority of JSF developers develop applications running in the browser. As things go, trying to keep developers from learning HTML, CSS and JavaScript turned out to be an illusion. As a consequence, both the core JSF standard and every popular JSF component framework have options to add JavaScript and CSS. That’s the ugly secret nobody tells you when you start programming JSF: good JSF developers have to be familiar with many technologies and at least two programming languages (Java and JavaScript). From this point of view, programming the browser directly with HTML, CSS and JavaScript seems to be simpler. However, JSF is a mature technology with a lot of industry support. It’s not likely to vanish within the next five years. The average JavaScript framework has a much shorter life expectancy. That’s one of the reasons why I believe JSF programmers are more productive than pure JavaScript programmers. Other reasons are the powerful tool chain and the seamless integration with the Java backend.

Until JSF 2.2, the key feature of JSF were its components. Components are the building blocks of JSF. I’ll list a couple of component libraries in a minute. As you’ll see, the range of components is impressive. There’s everything from simple input fields to full-blown map engines and statistical charts. Unfortunately, many people felt restricted by the pre-defined components, so JSF 2.2 added a second programming paradigm:

  • You can adopt an HTML5 coding style. More often than not, this will result in an HTML-centric coding style that doesn’t need JSF component libraries. Instead, you can use popular client-side components libraries like jQueryUI or Bootstrap. For example, there are two powerful client-side data tables for Bootstrap: Bootstrap-table and Datatables.net. The latter works both with or without Bootstrap.
    Following this approach takes most of the sting out of the flame wars against JSF. You still use some of the concepts of JSF, but you’re up to your own to use HTML, JavaScript and CSS the way you like. This approach is very attractive to many developers who are already familiar with web development.
  • You can employ a powerful component library like PrimeFaces or BootsFaces. These components offer a lot of features out-of-the-box, but they are usually a bit opinionated about how a UI should look like. Like said above, components are a mixed blessing. They serve almost every requirement, but sooner or later most projects are confronted with a requirement the component doesn’t quite meet. In such a situation, you’re stuck. JSF has been developer with extensibility in mind, but few developers dare to extend predefined components, so it’s an all-or-nothing game. Even so, the UI component libraries are one of the most compelling reasons to use JSF.

JSF component libraries: GISFaces

Let’s start with a small but exciting player. GISFaces is specialized on displaying maps. Using maps with GISFaces is surprisingly simple. GISFaces uses a number of maps services that are available publicly and for free, so I suppose you can use the maps in your own applications, even if you publish them on the internet1

Unlike most other JSF libraries, GISFaces is closed source. Plus, you need to register yourself before you can use it. But according to Chris Duncan, that’s not a big deal. His comment below has a lot of additional information on the registration process in particular and GISFaces in general.

JSF component libraries: PrimeFaces

These days, PrimeFaces is the most popular JSF component framework. It offers a rich set of components, including such exotic components for statistical charts and flowcharts. PrimeFaces also simplifies AJAX. Recent versions of PrimeFaces added support for mobile devices, accessibility (e.g. screen readers) and responsive design.

From today’s perspective, the default theme of PrimeFaces looks a bit old-fashioned. But that can be helped with a wide variety of predefined or custom themes. PrimeFaces supports Themeroller, so it’s easy to create a theme yourself. Or you can by a thema from PrimeTek, the company backing PrimeFaces, or a third-party vendor.

PrimeFaces is an open-source library published under an Apache V2 license. Only support and bug-fix releases cost money.

Cutting a long story short: PrimeFaces is highly recommended. Even if I’m the contributor to another JSF component framework that seems to be competition, I’m very impressed by PrimeFaces, and it’s always a lot of fun to use it.

JSF component libraries: BootsFaces

BootsFaces is a slightly smaller component framework build around the Bootstrap framework. In other words: responsive design and support for mobile devices where built in from day one. Originally designed to be a small framework concentrating on the layout, it rapidly grew to a full-blown JSF component library offering roughly 70 components.

BootsFaces generates much more compact HTML code than most JSF frameworks. Most components of BootsFaces generate a native Bootstrap component. Usually, that means compact HTML code. Most of the rendering takes place on the client, relieving the server from having to care about every aspect of the UI.

Other notable features are the advanced search expressions and the AJAX framework. Both have been inspired by PrimeFaces, but go far beyond. The general idea of BootsFaces is to simplify JSF. The innovative approach to AJAX is an example of this.

Like PrimeFaces, BootsFaces is published under a business-friendly Apache V2 license. Despite its low version number, it has attracted a lot of attention. The 2000 downloads-per-month mark has been crossed in May. That’s a much smaller market share than PrimeFaces has, but the figures keep growing, and BootsFaces has been designed with compatibility to PrimeFaces in mind. The goal of the team is not to replace PrimeFaces, but to allow cherry-picking.

JSF component libraries: ICEFaces and RichFaces

These are two early JSF component frameworks that used to be popular but have almost fallen into oblivion since then. If I’ve followed the new correctly, the development of RichFaces has been canceled this year (2016).

ICEFaces still seems to be an active project, but it’s lost much of its popularity in recent years. Among other things, there was some commotion when ICEFaces copied a lot of the source code of PrimeFaces without telling. Strictly speaking, this was legal (the Apache V2 license is very liberal), but the JSF community didn’t appreciate that. Be that as it may, ICEFaces added a couple of very interesting concepts to the JSF world. “Automatic AJAX” detected the changes of the JSF tree, allowing for much more efficient usage of the network. ICEFaces also was a pioneer in exploring push technology with JSF.

BabbageFaces

Talking of automatic AJAX, it might be interesting to mention BabbageFaces. That’s project of mine bringing automatic AJAX to the greater JSF world. BabbageFaces was very successful in the lab, but it didn’t work as well in the real world. It only works if the HTML code generated by your JSF page is valid XML code. That’s hardly ever the case, so I consider BabbageFaces an interesting but failed project. Plus, advances in network technology reduced the need for such a framework.

AngularFaces

Another canceled experiment of mine – but one that’s used by a small group of developers in production. The idea of AngularFaces was to eliminate AJAX request by moving the logic to the client. More specifically, the client uses AngularJS, which is very similar to JSF.

By the way, AngularFaces is not a component library. It’s designed to be a plugin to every other JSF framework (though it has only been tested with Mojarra and PrimeFaces).

AngularFaces attracted a lot of interest in the JSF community. In particular, developers working on JSF frameworks were fascinated. Developers just using JSF frameworks were a lot less fascinated. Most developers shied away from having to deal with both the complex lifecycle of JSF and AngularJS. In my eyes, the integration was successful enough to take the scare out of it, but since the general experience of software architects is to keep things simple, AngularFaces never took off. In a way, that’s a pity: it’s a good tool to migrate from JSF to AngularJS.

The next version of AngularFaces (if it ever materialized) will target Angular2 and – possibly – AngularBeans.

LiferayFaces

That’s a very active project targeting a highly specialized market: Liferay. As to my experience, it’s better to program Liferay natively (i.e. by using JSP and Spring MVC), but LiferayFaces offers an interesting bridge to the JSF world. It’s suffering from the same problem as AngularFaces: both Liferay and JSF have a complex lifecycle, and it’s not easy to integrate them. That’s not a small achievement. And it works: I’ve successfully developed JSF applications with LiferayFaces. There’s a major developer productivity penalty, but if you are already using Liferay for some reason, the advantage of LiferayFaces is that it integrates your JSF pages seamlessly with the AlloyUI theme of Liferay.

JSF component libraries: ButterFaces

ButterFaces is another component framework based on Bootstrap, but for some reason, it’s almost orthogonal to BootsFaces. It focused on components, neglecting the layout. In theory, that makes it the ideal companion framework to BootsFaces, but currently, it’s still a bit tricky to integrate the two frameworks. The teams are working on that.

Although this has little to do with the features and shortcomings of the framework itself, I’d like to point out the innovative interactive showcase of ButterFaces. It allows to manipulate the attributes of the ButterFaces components and to see the effect in real time.

JSF component libraries: HighFaces

HighFaces is a highly specialized JSF libraries focusing on charts rendered on the client side by Highcharts, a JavaScript library bringing interactive charts to the browser.

HighFaces is published under a business-friendly Apache V2 license. However, the underlying Highcharts JS library is not. It’s free for non-commercial use, but both commercial usage and support cost money.

JSF component libraries: TieFaces

TieFaces is a very similar library. It focuses on charts. Plus, it delivers Excel support. You can turn your browser into a spreadsheet using a few lines of JSF code.

Proprietary frameworks

There are also a couple of proprietary JSF frameworks. I won’t cover them not only because they aren’t open source, but because I’m under the impression that they have a limited market share. Suffice it to say they exist.

OmniFaces

Honestly, I can’t think of a JSF project without OmniFaces. OmniFaces is the Swiss army knife of the JSF world. At the same time, it’s a most unusual JSF framework. OmniFaces doesn’t bring many visual JSF components. Instead, it’s sort of orthogonal to other JSF component frameworks. It adds what’s seems to be missing in the core JSF framework. Notable examples are predefined universal converters, lazy loading of JavaScript libraries and much more. The developers of OmniFaces are members of the JSF 2.3 EG, which allows them to add popular features of OmniFaces to the JSF standard.

By the way, virtually every JSF developer knows one of the developers of OmniFaces by his nickname BalusC. He’s the helpful soul answering countless questions about JSF on StackOverflow.

State of the art (2016)


Putting it in a nutshell, JSF is an old technology. Many developers even consider it outdated. Plus, JSF isn’t a simple framework. It takes some time to master it. But that doesn’t mean it’s a bad framework. Quite the contrary, once you’ve mastered the learning phase, you can write JSF application surprisingly fast. JSF is particularly well suited to large-scale applications, i.e. the enterprise market. It’s not optimized for small applications or games. But it really shines in the class of application it’s designed for.

The advantages of JSF are its rich set of powerful component libraries, it’s sophisticated lifecycle, its built-in validation framework and its seamless integration with JaveEE2. The drawbacks are the component libraries, the lifecycle, the validation framework and the integration with JavaEE. Each of these features may stand in your way. For example, many developers try to combine JSF with Spring. That’s possible, but there are so many drawbacks that I’d call it a stupid idea. If you insist on using Spring, you’re better off with Spring MVC.

Uncertain future

Currently, there’s a lot of uncertainty whether Oracle is going to continue to support JavaEE 8 as it was planned a couple of years ago. There’s a major shift towards cloud computing, and in theory, this might result in Oracle dropping JSF. But I suppose the JSF community is vivid and strong enough to survive such a move. Countless companies use JSF. If Oracle were to stop JSF development, there’s probably a successor in no time. Plus, most of the progress of JSF is driven by the component libraries. But until JavaOne 2016 all this is speculation. The official statements of Oracle state they continue supporting JavaEE 8. That should include JSF. That’d be good news: a lot of effort already went into developing JSF 2.3.

Wrapping it up

Regardless of what they tell you, JSF isn’t dead yet. I’m not sure I’d base a new project on JSF (unless it’s based on BootsFaces, of course). But if you do, you don’t do anything wrong. JSF is a mature technology with a lot of freely available documentation, and it’s still evolving. Maturity may seem boring at first glance, bit it also means superior toolchains, high developer productivity, long-term support, and happy customers.

However, I’m not sure I’d start a major JSF project in 2016. Client-side frameworks and ecosystems like react.js and Angular2 are rapidly catching up, so maybe it’s time to migrate to JavaScript or TypeScript. However, the development in the JavaScript world is still so fast it’s difficult to choose the right framework if your application needs to be maintained five, ten or even twenty years.


  1. I recommend double-checking the license nonetheless. Many lawyers have specialized in charging people publishing maps, more often than not involuntarily violating copyright laws. That’s why I don’t publish screenshot of GISFaces here.
  2. This applies to JSF 2.2 and to JavaEE 7 and above.

How to Use Advanced Search Expressions with Mojarra, MyFaces or OmniFaces

I consider the advanced search expressions of PrimeFaces and BootsFaces tremendously useful. In particular, @next and @previous make it a lot easier to move input fields around on the screen or from one screen to another during the prototype phase of your project. The only problem with the search expressions is that they only work with PrimeFaces and BootsFaces components. If you also use the base components like <h:inputText />, you back to using ids and the four search expressions defined by the JSF standard (@form, @this, @all and @none).

JSF 2.3 may change that. It’s not settled yet, but there an ongoing discussion to include a similar search expression framework in JSF 2.3.

But what about now?

That’s a bright look-out. Problem is, most of us live don’t live in the future. Quite the contrary, from a technical point of view, most of us developer live in the past. I know many projects currently developed with JavaEE 6, a technology presented seven years ago. In other words: even if Oracle is going to accept our proposal in JSF 2.3, that doesn’t help many developers before 2020. So the challenge is to find a way to add the search expressions to JSF 2.0, 2.1, and 2.2.

How to do it

Cutting a long story short: I’ve found such a solution. It’s not exactly elegant, but it does the trick. The nice thing about my solution is that you don’t need to add the BootsFaces library to your project just to use the search expressions. You only need a single package of BootsFaces. Most likely I’m going to publish this package on Maven Central after running some more tests.

Actually, it’s fairly simple to use the search expressions in non-BootsFaces components. Every attribute of a JSF component supports EL expressions. This includes the attributes for, render and execute. So I’ve defined a JSF bean allowing you to resolve the advanced search expressions:

<h:message for=
 "#{searchExpressionResolverBean.resolve(component, '@previous')}" />

Of course, that’s a far cry from what we really want:

<h:message for="@previous" />

Luckily, there’s a second option we can use to simplify things. JSF allows us to register a “facelets decorator”. This class is called when the XHTML file is loaded and parsed. The facelet decorator can modify each facelet and replace it with another facelets. That’s how the HTML5 friendly markup of JSF 2.2 has been implemented. The JSF 2.2 recognizes an HTML input tag and replaces it with a JSF h:inputText if there’s an JSF attribute. We can use the same trick to replace the string "@previous" by "#{searchExpressionResolverBean.resolve(component, '@previous')}"". In other words, our decorator translates the search expressions to something core JSF can understand at load time.

How to activate the search expressions

Unless you’re already using BootsFaces, copy the folder https://github.com/TheCoder4eu/BootsFaces-OSP/tree/master/src/main/java/net/bootsfaces/expressions to your project. This folders contains the entire search expression resolver library, and it also contains the decorator in a subfolder.

If you want to benefit from the simplified syntax of the decorator, you have to activate it by adding a few lines to your project’s web.xml. If you don’t use BootsFaces, that’s:

    <context-param>
      <param-name>javax.faces.FACELETS_DECORATORS</param-name>
      <param-value>
          net.bootsfaces.expressions.decorator.SearchExpressionsTagDecorator
      </param-value>
    </context-param>

If you use BootsFaces, chances are you also want to benefit from the full power of the relaxed HTML5-like coding style of BootsFaces. If so, you have to register a different, more powerful decorator:

    <context-param>
      <param-name>javax.faces.FACELETS_DECORATORS</param-name>
      <param-value>
          net.bootsfaces.decorator.BootsFacesTagDecorator
      </param-value>
    </context-param>

Limits of the decorator

I encountered a surprising limitation of the decorator when I tried to use it with f:ajax. Both the render and the execute attribute are translated by the decorator, but they are ignored – at least by Mojarra (I didn’t try MyFaces yet). That’s fairly annoying because it forces you to use my first, verbose proposal. You can abbreviate the long name of the JSF bean SearchExpressionResolverBean by deriving a bean with a shorter name, but there’s no way to reach the simple syntax we really want.

Still, being able to use advanced search expressions with frameworks like Mojarra, MyFaces, RichFaces, or ButterFaces that haven’t been designed to be extended that way is nice.

Benefits for users of BootsFaces and PrimeFaces

Every once in a while, even users of such huge libraries like PrimeFaces (157 components) and BootsFaces (68 components) need a component that’s not part of the library. A popular way to build components is to build them from scratch using the base libraries. Another popular way is to add a library like OmniFaces, that’s not aware of the search expressions, either. But it does contain components like <o:commandScript /> that may benefit from the search expression.

By the way, if you prefer PrimeFaces over BootsFaces, you can also use their search expression framework. I didn’t prepare code to use it, but it’s fairly simple. The source code is at https://github.com/primefaces/primefaces/tree/master/src/main/java/org/primefaces/expression. The key class is the SearchExpressionFacade. There’s no facelets decorator, but I’m sure you’ll be able to migrate the BootsFaces facelets decorator to PrimeFaces within a few hours.

Benefits for the rest of the JSF world

Well, that’s fairly obvious: you couldn’t use the advanced search expression before. Now you can. More likely than not, you don’t see the use case use. But that shouldn’t stop you. Just give @next, @previous, @parent, @after, and @styleClass(.) a try. Before you know, you’ll be addicted. Using fixed ids may be the most efficient way with respect to CPU usage, but at the same time, it’s very inflexible and limited if your JSF views are changed frequently. The advanced search expressions of PrimeFaces and BootsFaces make moving fields from one panel to another or from one view to another a breeze.

Wrapping it up

JSF is very flexible. So it’s possible to add search expressions to JSF using a couple of tricks. However, the f:ajax facet of JSF seems to ignore the changes of the facelet decorators, so the result isn’t as nice as it’s intended to be. But still, it’s nice to able to use the advanced search expressions in JSF 2.2 or below.

Newsflash: OmniFaces 2.4 has been Released

OmniFaces 2.4 has been released. This time, the new version concentrates on bug fixing and polishing. There is only a handful of new features, the most notable being <o:url />, which bring the old <o:url /> of JSF 1.x back to the JSF 2.x world. There are also improvements to the FullAjaxExceptionHandler and better support for logging. As usual, the team has written an exhaustive blog post covering the changes, so I won’t repeat their description. Instead, I suggest you follow the links below.

JSF 2.3

Maybe more important is that the OmniFaces team brought a couple of features from OmniFaces to the upcoming JSF 2.3 standard. That’s exciting because it puts the commotion about Oracle’s presumed withdrawal from JavaEE into perspective. Even if the rumors we to come true and Oracle were to stop their efforts on JavaEE, it wouldn’t be the end of the Java world. If need be, there are other developers ready to contribute suggestions, improvements, code and documentation.

Dig deeper

Announcement written by BalusC
What´s new in OmniFaces 2.4?

What’s New in BootsFaces 0.8.5?

Fork me on GitHubWhat started as a small bugfix release, ended as a full-blown feature release. If the sheer number of commits is an indicator, the new release is awesome: the previous release counted 599 commits. In the meantime, 240 commits went into the 0.8.5 version, give or take a few. Needless to say, this amounts to a lot of added functionality: 11 new components, countless improvements and – of course – bugfixes. Plus, we’ve migrated the relaxed HTML-like markup style from AngularFaces to BootsFaces.

Continue reading

Type-safe Navigation in JSF

What to make of this? In general, I eagerly embrace everything offering type safety. However, in this particular case, I’m not entirely convinced. Probably I won’t use this feature in my projects any time soon. On the other hands, this stuff has so many options that it may easily pay off in larger projects. Especially, if some of the JSF views of your applications require authorization.

I’m talking about the “type-safe navigation” offered by the JSF module of Deltaspike. Basically, that’s a Java file describing every JSF page of your application.

Back to the future!

In a way, it’s funny that Deltaspike, which aims to improve JavaEE in general and JSF in particular, adds such a feature. One of the key advantages of JSF 2 was to get rid of the navigation rules file of JSF 1.x. Deltaspike brings it back, albeit in a different way.
Continue reading

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 Jaxenter.de 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:

<dependency>
    <groupId>net.bootsfaces</groupId>
    <artifactId>bootsfaces</artifactId>
    <version>0.8.1</version>
    <scope>runtime</scope>
</dependency>

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


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

Newsflash: Running Example of Spring Boot + JSF

Some time ago, I wrote about the challenges of getting JSF in a Spring Boot container up and running. The problem is that Spring Boot is officially not supported by the Mojarra team, which means it’s up to the Spring Boot team to ensure compatibility.

The Spring Boot ticket Phil Webb opened in response to my article is still open, but he pointed me to an interesting article. Alex Bath of Oakdale Software managed to run a JSF application on Apache MyFaces 2.2.6.

However, I suspect that compatibility between JSF and Spring will deteriorate more and more in the (possibly near) future. If I’m not mistaken, JSF is going to be tightly integrated with CDI, so many interesting features simply won’t work without CDI. On the long run, this may render JSF useless without CDI.

That said, I’d like you to point to the GitHub repository of the project of Alex and invite you to read the full story.

JSF ViewState and CSRF Hacker Attacks

One of the implementation details of JSF hardly any developer knows anything about is the hidden field “javax.faces.ViewState” that’s included in every JSF view. On the one hand, it’s good that you don’t have to know anything about this field. Thing is, this lack of knowledge is filled with many myths. One of these myths is that the view state protects JSF pages against “cross-site request forgery attacks” (CSRF for short). Which is true, but it’s not the primary purpose of the field.

I started to investigate the topic because our professional penetration tester managed to run a CSRF attack using a simple replay script. He made me believe that the view state doesn’t protect JSF application against CSRF attacks. But what is it for? And while we’re at it, how to protect your application against CSRF?
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:form>
   <h:inputText id="name" value="#{helloBean.name}">
   <h:commandButton value="Welcome Me">
      <f:ajax execute="name" render="output" />
   </h:commandButton>
   <h:outputText id="output" value="#{helloBean.sayWelcome}" />	
</h:form>

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:form>
   <h:inputText value="#{helloBean.name}" />
   <p:commandButton value="Welcome Me" 
                    process="@previous" update="@next" >
   <h:outputText value="#{helloBean.sayWelcome}" />
</h:form>

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}"  />
</p:inputText>
<h:outputText value="#{userBean.firstname}" />
 
<p:inputText value="#{userBean.lastname}">
     <p:ajax event="blur" 
             update="@next" listener="#{userBean.onBlur}"   />
</p:inputText>
<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');
                      ajax:userBean.onKeyUp;
                      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?


How to Detect a Page Reload in JSF

One of our customers wants to reload everything from scratch when they hit the F5 key. Many web applications work like that, so customers have learned over the years that a page reload gives you fresh data. Usually that works because the web application doesn’t cache data in the session or view scope.

Unfortunately, some of our database queries take a long time, so we need caching. Reloading everything from scratch during each request is not an option. So we need to detect the F5 key. Plus the browser’s reload button, plus the reload command of the browser’s context menu.

At first, I didn’t think it wasn’t possible to accomplish this. At least not in a generic way. You know, the F5 button simply causes a GET request. The challenging part is to find out that the user has not clicked a button before.

After some investigation on the web, I came up with a clumsy solution. When I implemented it, I realized that there’s also a simple solution. The only problem is, I don’t know yet why it works (which makes me skeptical).
Continue reading

Updating To Mojarra 2.2.11+ May Break Your Spring Boot Application

One of our BootsFaces users surprised me by reporting that his application ceased to work after updating to Mojarra 2.2.11. After some investigation, I found out that the Mojarra team had implemented something that looked like an optimization. It works fine on a traditional Tomcat, but it doesn’t on Spring Boot.

What happened?

After reporting the bug to the Mozilla team, I learned two things:

  • Spring Boot is not officially supported by the Mojarra team. They’ll accept your bug fixes happily, but they’re reluctant to fix bugs related to Spring Boot themselves. Now, that shouldn’t come as a surprise. Spring considers itself as a competitor to JavaEE, so it’s just a happy coincidence that it’s possible to combine Spring Boots and JSF.
  • There was a good reason to implement the breaking change, and it wasn’t performance.

Continue reading

How to Embed a Servlet or an HTML Page in a JSF 2.x View

As trivial as the task may sound, hardly anybody seems to embed a servlet or an HTML page in a JSF view. That’s the impression my team and I got after a lengthy Google investigation. Finally we found OmniFaces, better known as the Swiss Army Knife of JSF.

OmniFaces is one of those JSF libraries that are different: It’s not about visual widgets (not in the first place, at least), but it’s full of other useful stuff. There’s the FullAjaxExceptionHandler BeyondJava.net reported about in an earlier article. There are several useful converters that make using comboboxes (or SelectOneMenus in JSF speak) much simpler. There’s the useful CombinedResourceHandler I’m going to cover soon. And there’s the component of the day: <o:resourceInclude />.
Continue reading

Final Version of AngularFaces 2.1 Published

Fork me on GitHubAngularFaces 2.1 is more than a bug fix release. It contains a couple of features I deliberately postponed in order to get a thoroughly tested version 2.0 out in times. The list below counts no less than 15 improvements. One of the improvements has nothing to the with code: I put AngularFaces 2.1 under an Apache V2 licence, which is much more liberal than the GPL licence of the previous version.

Examples and code snippets

Pictures say more than words, so let’s start with a couple of screenshots and code snippets. Click the tabs to see the source codes.

ng-table is a great client-side datatable component written in AngularJS. Thus, it’s a natural fit to AngularFaces.

<table ng-table="tableParams" class="table ng-table-responsive">
  <tr ng-repeat="car in $data">
    <td data-title="'Brand'" sortable="'brand'">{{car.brand}}</td>
    <td data-title="'Type'" sortable="'type'">{{car.type}}</td>
    <td data-title="'Year'" sortable="'year'">{{car.year}}</td>
    <td data-title="'Color'" sortable="'color'">{{car.color}}</td>
    <td data-title="'Mileage'" sortable="'mileage'">{{car.mileage}}</td>
    <td data-title="'Price'" sortable="'price'">{{car.price}}</td>
    <td data-title="'Fuel'" sortable="'fuel'">{{car.fuel}}</td>
    <td data-title="'Select'">
      <button class="carFilterButton" jsf:action="#{selectionBean.showDetails()}"
        ng-click="selectionBean.carAsJSon=afToJson(car);">show me!</button>
    </td>
  </tr>
</table>
<input jsf:value="{{selectionBean.carAsJSon}}" style="display:none" addLabel="false"/>
<prime:messages globalOnly="false" />
var app = angular.module('CarShop', ["angularfaces", 'ngTable', 'ngTableExport']).
controller('CarShopController', function($scope, $filter, ngTableParams) {
  // This initializes the Angular Model with the values of the JSF bean attributes
  initJSFScope($scope);
  $scope.activeSelections=0;
  
  $scope.select = function(car) {
    console.log(car);
    $scope.selectionBean.carAsJSon=car;
    return true;
  }
  
  $scope.showIfSet = function(ngmodel) {
    if (typeof(ngmodel)=='undefined') {
      return "hidden";
    }
    if (null==ngmodel || ngmodel=="") {
      return "hidden";
    }
    $scope.activeSelections++;
    return "";
  }
  
  $scope.filterBoxStyle=function(){
    var width=400+100*$scope.activeSelections;
    return "" + width + "px";
  }
  
    $scope.tableParams = new ngTableParams({
        page: 1,                  // show first page
        count: 10,                // count per page
        sorting: { brand: 'asc' } // initial sorting
    }, {
        total: $scope.carPool.selectedCars.length, // length of data
        getData: function($defer, params) {
          params.settings().counts=[5, 10, 'all']; // todo: that's a hack!
          var rows = $scope.carPool.selectedCars;
          if (params.filter()) rows=$filter('filter')(rows, params.filter());
          if (params.sorting()) rows = $filter('orderBy')(rows, params.orderBy());
          var page = params.page();
          var pageLength = params.count();
          if (pageLength=='all') 
          $defer.resolve(rows);
          else
            $defer.resolve(rows.slice((page - 1) * pageLength, page * pageLength));
        }
    });

})

Many business applications consist of long forms. AngularFaces simplifies writing such forms by adding labels and messages (including internationalization) automatically. If possible, it validates the form on the client, thus reducing the server load.

     <prime:panel header="If you want to buy this car..."
        ng-show="{{doShowDetails()}}" styleClass="{{showDetailsClass()}}">
        <prime:panelGrid columns="3" style="border: 0px;">
          <prime:inputText value="#{carBean.brand}" />
          <prime:inputText value="#{carBean.type}" />
          <prime:inputText value="#{carBean.price}" />
          <prime:inputText value="#{carBean.mileage}" />
          <prime:inputText value="#{carBean.color}" />
          <prime:inputText value="#{carBean.year}" />
          <prime:inputText value="#{carBean.fuel}" />
        </prime:panelGrid>
      </prime:panel>
      <prime:panel
        header="... we need some informations about where to deliver it:"
        ng-show="{{doShowDetails()}}" styleClass="{{showDetailsClass()}}">
        <prime:panelGrid columns="3" style="border: 0px;">
          <prime:inputText value="{{customerBean.lastName}}" />
          <prime:inputText value="{{customerBean.firstName}}" />
          <prime:inputText value="{{customerBean.dateOfBirth}}" />
          <prime:inputText value="{{customerBean.emailAddress}}" />
          <prime:inputText
            value="{{customerBean.iAgreeToTheTermsAndConditions}}" />
        </prime:panelGrid>
      </prime:panel>
      <prime:panel
        header="Please confirm you are a human by answering this simple question:"
        ng-show="{{doShowDetails()}}" styleClass="{{showDetailsClass()}}">
        <prime:panelGrid columns="3" style="border: 0px;">
          <prime:outputLabel for="captchaField"
            value="{{customerBean.captchaQuestion}}" />
          <prime:inputText required="false" id="captchaField"
            value="{{customerBean.captcha}}"
            ng:captcha="{{customerBean.expectedCaptcha}}" />
        </prime:panelGrid>
      </prime:panel>
      <prime:commandButton 
        action="#{customerBean.buy(carBean)}"
        value="Buy this car! (Non-AJAX)" ajax="false"
        styleClass="carFilterButton {{showDetailsClass()}}" ng-disabled="myForm.$invalid"
        style="{{myForm.$invalid?'color:#888':''}}" />
var app = angular.module('CarShop', ["angularfaces"]).
controller('CarShopController', function($scope, $filter) {
  // This initializes the Angular Model with the values of the JSF bean attributes
  initJSFScope($scope);
  $scope.doShowDetails = function() {
    if (typeof($scope.customerBean)=="undefined"||
      typeof($scope.customerBean.showDetails)=="undefined") {
      return false;
    }
    return $scope.customerBean.showDetails;
  }
  $scope.showDetailsClass = function() {
    if ($scope.doShowDetails()) 
      return "";
    else
      return "hidden";
  }
  $scope.showFinishedTransactionClass = function() {
    if ($scope.doShowDetails()) 
      return "hidden";
    else
      return "";
  }
  
  $scope.buttonEnabledStyle = function() {
    if ($scope.myForm.$invalid) 
      return "color:#888";
    else
      return "";
  }

});

app.directive('captcha', function() {
  return {
    require : 'ngModel',
    link : function(scope, elm, attrs, ctrl) {
      ctrl.$parsers.unshift(function(viewValue) {
        if (typeof(viewValue)=="undefined" || viewValue==null) {
          ctrl.$setValidity('captcha', false);
          return viewValue;
        }
        if (viewValue!=attrs["captcha"]) {
          ctrl.$setValidity('captcha', false);
          return viewValue;
        } else {
          ctrl.$setValidity('captcha', true);
          return viewValue;
        }
      });
    }
  };
});

The JSF view below shows how to exchange arbitrary data between client and server using the new <ngsync /> tag.

The form contains seven input fields, so the XHTML code repeats itself. I omitted most of the repetitions. The XHTML code uses the new HTML5 style of JSF 2.2:

    <ngsync value="{{staticOptionBean.brands}}"   direction="serverToClient" once="true" />
    <ngsync value="{{staticOptionBean.colors}}"   direction="serverToClient" once="true" />
    <ngsync value="{{dynamicOptionBean.types}}"   direction="serverToClient" cacheable="true" />
...
    
    <!-- ngsync doesn't transport the entire bean recursively, so we have to list each attributes we want to send -->
    <!-- will be fixed in a future AngularFaces version -->
    <ngsync value="{{filterBean.type}}"     direction="serverToClient" cacheable="true" />
    <ngsync value="{{filterBean.brand}}"    direction="serverToClient" cacheable="true"/>
    <ngsync value="{{filterBean.counter}}"  direction="serverToClient" cacheable="true" />
    <!-- end of ngsync workaround -->
    
    <ngsync value="{{filterBean}}" direction="clientToServer" id="filterSyncID" />
    <ngsync value="{{settingsBean}}" direction="clientToServer" id="settingsID" />
    
    <div class="carFilterBox"> 
      <div style="font-weight:bold;font-size:125%">What kind of car are you looking for?
      </div> 
      <div>
        <table style="border-spacing:10px">
          <tr>
            <td width="150px">Brand</td>
            <td width="110px">Type</td>
            <td width="100px">Price</td>
          </tr>
          <tr>
            <td>
              <select id="filterbrand" ng-model="filterBean.brand" ng-options="brand for brand in staticOptionBean.brands track by brand"
                                    ng-change="filterBean.type=''">
                     <option value="">-- choose brand --</option>
              </select>
            </td>
            ...
          </tr>
          ...
           <tr>
            <td>
              <select ng-model="filterBean.yearText" ng-options="year for year in staticOptionBean.years track by year">
                     <option value="">-- choose year --</option>
                 </select>
            </td>
            <td>
              <button ng-show="activateAJAXButton()" class="carFilterButton" jsf:action="index.jsf">update counter
                <f:ajax render="angular" execute="filterSyncID settingsID"></f:ajax>
              </button>
            </td>
            <td >
              <button id="listCarsID" class="carFilterButton" jsf:outcome="table.jsf" >{{filterBean.counter}} cars</button>
            </td>
          </tr>
        </table>
      </div>
    </div>
var app = angular.module('CarShop', [ "angularfaces" ]).controller(
    'CarShopController', function($scope) {
      // This initializes the Angular Model with the values of the JSF
      // bean attributes
      initJSFScope($scope);
      
      $scope.activateAJAXButton = function() {
        if ($scope.settingsBean.updateImmediately)
          return false;
        else
          return true;
      };
      
      $scope.sendFilterToServer = function(newValue, oldValue) {
        if ($scope.settingsBean.updateImmediately) {
          if (newValue != oldValue) {
            try {
              $scope.afSendNGSyncToServer();
            } catch (e) {
              console.log("Ein Fehler ist aufgetreten: " + e);
            }
          }
        }
      };

      $scope.$watch('filterBean.brand', $scope.sendFilterToServer);
      $scope.$watch('filterBean.type', $scope.sendFilterToServer);
      $scope.$watch('filterBean.price', $scope.sendFilterToServer);
      $scope.$watch('filterBean.mileage', $scope.sendFilterToServer);
      $scope.$watch('filterBean.fuel', $scope.sendFilterToServer);
      $scope.$watch('filterBean.color', $scope.sendFilterToServer);
      $scope.$watch('filterBean.yearText', $scope.sendFilterToServer);
    })

Continue reading

BootsFaces 0.6.0 Now Available on Maven Central

Maven coordinates

BootsFaces – the JSF framework that makes Bootstrap much more accessible to JSF programmers – is now available on Maven Central. To use it, add a dependency to your Maven pom.xml file:

<dependency>
    <groupId>net.bootsfaces</groupId>
    <artifactId>bootsfaces</artifactId>
    <version>0.6.0</version>
</dependency>

Gradle users activate BootsFaces by adding this line to their .gradle build file:

compile 'net.bootsfaces:bootsfaces:0.6.0'

Minified version and debug-friendly version

The version I’ve uploaded to Maven Central is a developer-friendly version containing minified Javascript and CSS code, but non-minified Java class files. In other words: you can debug it, and you can easily identify the offending line if you find an error in your production log.

There’s also a version of BootsFaces that has been minified more aggressively. Currently, the smaller and slightly faster version hasn’t made it to Maven Central yet. You can download it at our project showcase and the project GitHub repository.

License

BootsFaces 0.6.0 is available both under a GPL 3 and a LGPL 3 license.

But I’m already using another JSF framework!

BootsFaces coexists peacefully with PrimeFaces, AngularFaces and probably most other JSF frameworks. For example, you can use the layout components of BootsFaces (<b:row>, <b:column>, <b:panelGrid>, <b:panel>, <b:tabView> / <b:tab> and <b:navBar>) together with the powerful input and datatable widgets of PrimeFaces.

Of course you can also use BootsFaces as a full-blown JSF component framework, providing responsive design and native Bootstrap GUIs. It’s up to you.

Kudos

BootsFaces is an open source framework initiated and led by Riccardo Massera. Thanks to Riccardo, Emanuele Nocentelli and everybody else who contributed! This includes everybody who gave us feedback by reporting errors or feature requests by opening an issue on the GitHub repository. Your feedback matters!

Wrapping it up

Visit our project showcase and enjoy!

Newsflash: BootsFaces 0.6 released

Yesterday, BootsFaces 0.6 has been released. You can download it at the BootsFaces documentation pages.

Among other things, there are six new components (checkbox, combobox, panel grid, tab and a password input field). BootsFaces now is compatible to both Oracle MyFaces and Apache MyFaces 2.2. The next version 2.1 of AngularFaces will also support BootsFaces (and vice versa).

BeyondJava.net will report about BootsFaces in more detail soon. By the way, I (Stephan Rauh) joined the BootsFaces team recently, so I can give you first-hand informations about the project.

How to Modify JSF Library Load Order

Why ordering matters

Every once in a while it’s important to control the order in which JSF libraries are loaded1. For instance, loading the LiferayFacesBridge 6.1 before PrimeFaces 5.x breaks the AJAX features of PrimeFaces. Both libraries replace the same Mojarra or MyFaces base class by their own, improved implementation. Unfortunately Liferay doesn’t cope with the implementation of PrimeFaces. Loading PrimeFaces first fixes the problem.

There are many more examples. JSF libraries such as OmniFaces, AngularFaces and BabbageFaces don’t provide widgets. Instead, they modify the way JSF requests are processed2. Those processors stack behind each other like a pipeline. It’s easy to imagine situations in which the reordering the pipeline makes a difference. For instance, it’s important that BabbageFaces is the last stage of the pipeline: it optimizes the HTML code generated by the previous stages.

This article shows how to modify the load order of JSF libraries.


Continue reading

  1. more precisely: the order in which the libraries are configured and activated. However, the difference isn’t important for this article, so I’ll stick with the more common notion of “load ordering”.
  2. At this point, I deliberately oversimplify things a bit to keep language simple

Build Your Own Dependency Injection Framework!

Let’s bust a myth. There are very good reasons to use CDI or Spring, but dependency injection isn’t one of them. There are a lot of alternatives. And I’m not talking about Google Guice, although that’s a very fine DI framework indeed. Why don’t we write our own DI framework? Can’t be difficult, can it?

It’s true: today’s open source libraries make writing your own DI framework incredibly simple. But even without such a library writing a DI framework isn’t difficult (at least if you’re ready to learn something about class loaders). I’ll develop a sketchy DI framework in this article. In theory, you could finish my work to implement a full-blown DI container and put it into production. Even if you don’t, you’ll understand how CDI and Spring work after reading this article.

But first I’d like to present you an alternative you’re probably not aware of.
Continue reading