JSFlive starts a small series about JSF composite component pitfalls. While composite components really simplify the life of JSF developers in most cases they (still) have some minor quirks from time to time. The first post in this series Composite component pitfalls: Empty attributes discusses problems with composite component attributes whose value is null.

JSFlive shows how to run JSF applications (MyFaces and Mojarra) on Jetty 8: http://jsflive.wordpress.com/2012/08/19/jsf-2-on-jetty-8/

The current issue (4.2012) of the german Eclipse Magazin (http://eclipse-magazin.de) includes the article “CDI für Richt Clients” from Jakob Korherr (Software Engineer at IRIAN).

This article explains how it was possible to integrate Apache OpenWebBeans (CDI implementation from Apache) and Apache MyFaces CODI in an existing Eclipse RCP project and how the project benefited from it.

Here is the original blog post from Jakob: http://www.jakobk.com/2012/05/cdi-fuer-rich-clients-in-eclipse-magazin/

Irian will be at the JAX 2012 in Mainz. Michael Kurz will do the session JSF 2 Kompositkomponenten im Einsatz on 19th April 2012.

The slides and examples are available for download.

 Marrying JSF and Scala part 3: Custom Components in Scala

Introduction

While JSF2.0 has simplified the component building a lot thanks to the
composite components, there are still usecases when the classical component
building tasks have to be performed.

We showed in part 1 and part 2 how to build the basic JSF artifacts in Scala we now are going to dive deeper into JSF by showing how to leverage Scala to build your own jsf custom component.

In this article we combine various techniques of Scala for programming custom components.
The case we are going to investigate is a simple hello world component.

A custom component in Scala

First we have a look at the component itself:
 

Code a) Custom component

We have a simple component which exposes one additional attribute sayHello2. The component itself is a composite component with an xml template for rendering an performs some listener tasks.

So far so good, however we use several things here which are of interest:
 

Code b) Singleton

• A singleton object for static replacements and struct replacements

Code c) Listeners Array

• A listeners array for combining multiple listeners 

Code d) trait 

• a trait instead of a utils class to combine common functionality of components 

Code e) Type matches

• matches for types to avoid instanceof cascades

Lets dissect the code parts one by one:


1) Object HelloWorld

Scala does have neither static variables nor structs, instead of that it provides singletons as language construct.
Static variables simply can be simulated by a singleton and a simple in class import:
 

Code b) Singleton 

 and then
 

 Code f) import

Allows you to import the instance variables and methods as semi native members.
 

 Code g) import usage

2) Annotation Arrays
 

 Code h) annotation array Scala

is simply what would be in Java

 Code i) annotation array Java

Since this code transition is not quite obvious even within the Scala documentation, it is worth to be noted in this blog.

3) Traits

The most interesting part is the traits part.
First of all, what is a trait? To sum it up, a trait is an abstract class which can be multiply inherited sort of an interface with code. Now this opens quite a few possibilities:

• Common constraints can be isolated and shared among object instances without having to revert to singletons.
• Traits can access "this" and can call methods provided by the class as abstract members.

We reuse traits in this case to isolate common component behavior without having to introduce yet another helper class or an abstract base class.

In fact we finally can share this referencing code among components with different base classes without having to introduce our own inheritance hierarchy.

The trait looks like following:
 

 Code j) Trait

We use only a subset of this functionality namely getAttr and setAttr.

 

 Code k) getAttr

Here we can see clearly the this reference to the underlying component getAttributes with

def getAttributes(): java.util.Map[String, AnyRef]

being defined only as interface, which has to be implemented by the component or one of its parents.

4) Match patterns

Now an interesting language part in Scala is the extended matches. Not only you can match in Scala for values, also matches for types and patterns are allowed.
We use the type matches to avoid instanceof if cascades:
 

 Code l) match patterns

The cases basically replace if instanceof constructs here


 A renderer in Scala

Now what if we want to write the renderer in Scala.
Scala there can support us as well, it has XML support in the language baked in.
Now lets have a look at the renderer (if not done in an xhtml template like it should be)
 

 Code m) renderer

Now the interesting part of this renderer is following code:

 Code m) render part

As we can see, we simply write the html directly constructs like     id={id} and {text} allow for inline templating.

There are constraints to this approach

• We cannot write out partial xml. The xml written always must be complete, hence we cannot simply write an open tag first, call a subclass and then close the tag
• We do not use the startElement, endElement. The plus side is readability. 
• In the end a composite component and its direct xhtml rendering should always be the first choice. Xhtml simply is the target platform in most cases why not use xhtml also for the component renderer part.

References

1. Marrying JSF and Scala Part1
2. Marrying JSF and Scala Part2
3. Custom Components in JSF (German)
4. Scala Documentation