Now that's a surprise: AngularFaces becomes more powerful by getting rid of it's widgets. Quite a development for JSF widget library.
Instead of defining its own widgets AngularFaces 2.0 pimps up widgets provided by other widget libraries. In particular, it adds AngularJS to the new JSF 2.2 HTML5-style widgets. But of course it doesn't stop there. It's also compatible to the widgets of Mojarra and MyFaces and to many PrimeFaces widgets. Plus, it allows AngularJS to modify almost every JSF attribute.
In the meantime I've released the final version of AngularFaces 2.0, so you may also be interested in the announcement of the final version.
What's in store for you
You may already have guessed it: AngularFaces underwent a profound overhaul during the last three weeks. Now it's much more versatile and much more "Angular". Let's summarize the key points of AngularFaces 2.0:
- It integrates AngularJS and JSF seamlessly. The difference between the two technologies becomes blurry. It doesn't matter if you modify an attribute on the server side or in your AngularJS code. Both options are available to you. You can even do both, if you insist.
- In particular, JSF bean attributes are mapped into the AngularJS model. The mapping works in both directions, of course: the next request transfers changes made on the client side back to the server. After processing the user input the server update the AngularJS model again.
- Bean validation attributes (JSR 303) are evaluated on the client side by AngularJS (resembling the Client Side validation of PrimeFaces).
- Labels and error messages are added automatically to your input field (unless you tell AngularFaces otherwise).
- AngularFaces 2.0 makes internationalization much less scary. Translating your application into another language becomes very simple.
- AngularFaces 2.0 takes a new approach to AJAX. Mind you: you don't need server side rendering when you're using powerful Javascript widgets, so I reduced the AJAX responses to the attribute value updates, making them fast and slim.
- Every AngularJS attribute is treated as a pass-through attribute. You don't have to declare it explicitly as a pass-through attribute. For instance,
ng-show,ng-hideand many more can be used in the JSF file the way you'd use it in a pure AngularJS application.
As a result, AngularFaces views are pretty fast, contain very little boiler-plate code and may look almost like a native AngularJS page. Everybody coming from Javascript programming will get to speed in virtually no time. However, transition from JSF is smooth: you're free to write a traditional JSF page with a few AngularJS additions.
JSF - the Angular way
Let's have a look at an example.
This source code is a traditional PrimeFaces JSF file, only the JSF value expressions #{...} are replaced by AngularJS mustaches {{...}}. AngularFaces reads the value from the JSF bean (if it exists) and feeds it into the AngularJS model. When you push the first command button, AngularFaces takes the value from the AngularJS model and sends it back to the JSF bean.
That's the general idea of AngularFaces 2.0: it allows you to adopt both an Angular or a JSF style. It's your choice.
Getting rid of boiler plate code
In case you're missing essential stuff like labels, messages, validation constraints and internationalization: it's all there. I don't like boiler plate code, so AngularFaces adds it automatically for you (unless you configure it not to do). You've already seen some of it in the example's preview tab.
Bringing the bean validation API to the client
AngularFaces automatically evaluates the most important JSR 303 annotations on the client. Currently, it supports @Max, @Min, @Size and @NotNull (which is translated to a mandatory input field). It also determines the value of the JSF attribute. If it's a number, an HTML5 spinner is "automagically" added. Similarly, starting with AngularFaces 2.0 RC2 date fields are given a date picker.
Labels and messages
Labels are added automatically to input fields. In the JSF world it's a good practice to add the label property to an input field. Standard JSF uses the label attribute only in error messages. AngularFaces uses the same attribute to guess the text of the label. In case you omit the label, AngularFaces does even more guesswork. It simply assumes the value attribute to be the label in camel case notation. So attribute names like "randomNumberFromServer" are neatly displayed as "random number from server". It's astonishing how often this approach works.
Deliver your JSF page in several foreign languages
That's nice for the english speaking world, but the majority of languages have a more complex grammar. The camel case approach doesn't work in many languages. That's not a big deal, because I promised automatic translation anyways. "Automatic" means you have to provide a property file containing the translations, but apart from that you don't have to do much. Don't bother with the standard JSF approach, forcing you to write every label like i18n["WelcomeToAngularFaces2"]. Simply write what you want to express, and leave the rest to AngularFaces: