; last updated - 4 minutes read

Update February 2019, 26

This article describes my first attempt to make JSF a developer-friendly space. It's what I did seven years ago. In the meantime, I've implemented the feature in AngularFaces. At the time, I was proud of the feature, and I still am. It's just great, especially for rapid prototyping.

For some reason, the idea never took off. Few developers picked off the idea. If you're a JSF programmer, reducing the amount of boiler-plate code isn't your number-one-priority. Most JSF developers I've talked to are just happy to get the job done, no matter how ugly or tedious it is.

So I never migrated the feature to BootsFaces. In a way, that's a pity. Doing so would be easy. However, the market (that's you!) decided, and this article is only interesting from a historical point of view.

That's how my journey into JSF in particular and open-source software development in general began.

Fighting boiler-plate code!

This is the first part of a multipart series showing you how to make writing JSF page more fun. You'll get better results writing less code.

Let's have a look at a simple, yet typical form consisting of a single input field:

JSF source code

We have to write three lines of code to implement one input field. Looking carefully at the code, you see the repetitions:

JSF source code with annotations showing the repetitions

We repeated both the id and the label twice. In most cases, it is important to repeat them exactly. Any typo prevents the error message to be shown, or it is shown, but it confuses our user by showing the wrong label. I consider this a little annoying. Mind you, if you look at the <input>-line, there is everything that is needed to render both the label and the error message:

boiled-down JSF source code

Looking for a way to simplify my JSF code like this I investigated the new JSF 2.0 custom components. They look promising, indeed, and you can accomplish our task by writing a custom component. Unfortunately, custom components have many limitations. For example, I didn't find a way to align both the label and the input field of a custom component to a similar custom component in the next line. Another problem is the expression language; sooner or later you want to use nested expressions, but JSF 2.0 doesn't allow you to do so. In my case, I wanted to use nested expressions, because my application has to be able to support a variety of languages spoken in Europe. The internationalized version of our example looks like this:

internationalized JSF source code

If a backing bean provides the label text, we get nested EL expressions like this:

internationalized JSF source code

At this point, one thing should have become obvious: JSF 2.0 is great, but there are a few glitches. I could fix these glitches in the JSF libraries, or I could write custom components JSF 1.0 style. I came up with another solution: generating code. My idea is to write the code that is needed. As to my conviction, an input field should be expressed by a single line, like this:

boiled-down JSF source code

Adding the label, the error message, the internationalization and dealing with nested expressions are tedious tasks. In other words: they should be done by our computer. Computers are better than us when it comes to repeat boring tasks over and over again.

Our way to accomplish this simplification was to teach our build scripts to do the code generations. That is surprisingly easy. Have a look at my little bean validation magician to get an idea how to cut verbose JSF files short. In a way this is like moving from Java to Groovy: it's still the same language, but you get rid of the annoying boilerplate code.


Comments