new SelectItem(Title.MISS, "Miss");

Working with before JSF 2.0 was often tedious as you needed to write code to adapt your domain objects into . JSF 2.0 has improved things a lot and you can now dynamically construct using EL expressions. For example:

<h:selectOneMenu>
 <f:selectItems value="#{customerRepository.all}" var="customer" label="#{customer.name}"/>
</h:selectOneMenu>

This certainly helps to reduce the amount of boiler-plate code, however, I still think that there are things that we can do make even easier to use, especially when working with Spring. With that in mind, I have been developing a component, intended as a drop-in replacement for .

The first thing we can do, is help to reduce boiler-plate typing by removing the need to specify a attribute. With , if the attribute is not specified then it will default to . So the code above can be written:

<h:selectOneMenu>
 <s:selectItems value="#{customerRepository.all}" label="#{item.name}"/>
</h:selectOneMenu>

In the above example, the is being bound to a repository Interface that returns a of entities. As with the standard components you can also bind to an or . In addition the new component also supports any comma separated value.

<h:selectOneMenu>
 <s:selectItems value="Java, Spring, JavaServer Faces"/>
</h:selectOneMenu>

The next thing that can help with is values. It is quite common to need a “Please Select” option in drop downs to represent s. In vanilla JSF this can often mean additional mark-up for each component:

<h:selectOneMenu>
 <f:selectItem label="--- Please Select ---" noSelectionOption="true" itemValue=""/>
 <s:selectItems value="'{items}"/>
</h:selectOneMenu>

Instead of needing this additional mark-up for each element, our component will automatically insert a “Please Select” option whenever it is linked to a component. You can use the attribute to override this behavior. The label used for the “no selection option” will default to “— Please Select —” but you can customize and internationalize this text easily by adding a to your that can resolve the code .

On the subject of , the component will, whenever possible, try to create the label of the using a . I have blogged in the past about how to convert to messages and this component simply makes use of those ideas.

The new component has helped us when creating the to display, but what about dealing with form submit? How do you convert the submitted option back to a real ? in the initial example above, we are binding to JPA entities; The values will display just fine, but when you submit a form a “Conversion Error” is displayed because JSF does not know how to get from the submitted back to the object. The usual answer here is to develop your own implementation, but this is often problematic. Often you your select item value will be some complex object that is hard to represent in its entirety as a .

There is an interesting technique that you can use when writing a Converter that will be used with a or component. You actually only need write code to convert from the to a , conversion in the other direction can be accomplished by iterating the s and returning the single value that, when converted to a String, matches your submitted value. You can read more about the idea in this blog post by Arjan Tijms. Using this technique with the component is really easy, simply provide a attribute that will be used to create the unique value:

<h:selectOneMenu>
 <s:selectItems value="#{customerRepository.all}" label="#{item.name}" itemConverterStringValue="#{item.id}"/>
</h:selectOneMenu>

In actual fact the is optional. If you don’t specify it, the method of the object will be used or, in the case of a JPA , the field will automatically be used. You are still free to write and attach your own Converter if you need to, in such cases the is ignored.

Finally that is one more trick that the can perform. If you select component is bound to a or an then the attribute can be completely omitted. The select items will be built based on all possible options that the binding supports (“Yes”/”No” for or the complete set of values). This also works with typed collections. For example, the following will display the options “Java”, “Spring” and “JavaServer Faces” (assuming you have an appropriate ) :

public enum Technology {
 JAVA, SPRING, JAVASERVER_FACES
}

public class Bean implements Serializable {
 private Set<Technology> technologies = new HashSet<Technology>();
 // ... getters and setters
}

<h:selectManyCheckbox value="#{bean.technologies}">
 <s:selectItems/>
</h:selectManyCheckbox>

Reference: Integrating Spring & JavaServer Faces : Select Items from our JCG partner Phillip Webb at the Phil Webb’s Blog blog.