Thursday, March 22, 2012

In JSF input components have a label attribute that is typically used in (error) messages to let the user know about which component a message is. E.g.

Name: a value is required here.

If the label attribute isn't used, JSF will show a generated Id instead that is nearly always completely incomprehensible to users. So, this label is something you definitely want to use.

Of course, if the label is going to be used in the error message to identify said component, it should also be rendered on screen somewhere so the user knows which component has that label. For this JSF has the separate <h:outputLabel> component, which is typically but not necessarily placed right before the input component it labels.

The problem

The thing is though that this label component should nearly always have the exact same value as the label attribute of the component it labels, e.g.

There's a duplication here that feels rather unnecessary (it feels even worse when the label comes from a somewhat longer expression, which is typical for I18N). My co-worker Bauke identified this problem quite some time ago.

Finding a solution

It appears though that an implementation that automatically sets the label attribute of the target "for" component to the value of the outputLabel isn't that difficult, although there are a couple of things to keep in mind.

For starters, a component in JSF doesn't directly have something akin to an @PostConstruct method in which you can set up things. There are tag handlers and meta rules in which you can set up attributes, but when they execute not all components have to exist yet.

Luckily, we always have the plain old constructor and since JSF 2 components can register themselves for system events. This gets us into a method where we can setup things.

Additionally, we have to be aware of state. System event listeners are luckily not stateful, so perfectly suited for tasks that need to be setup once (Phase listeners are stateful though, and will 'come back' after every postback). Attributes of a component are by default stateful, so we only need to set those once, not at every postback. Finally, the API distinguishes between deferred expressions (value expressions) and literals. If we want to support dynamic labels and only want to setup the wiring once, it's important to take this distinction into account.

Finally, when searching for the target "for" component we can take advantage of the fact that typically this component will be close by. Compared to the regular search on the view root, the well-known "relative-up/down" search algorithm is probably more efficient here. This algorithm will start the search in the first naming container that is the parent of the component from where we start our search in the component tree. This will work its way up until there are no more parents, and if the component then still isn't found (practically this is rare if the component indeed exists), then a downward sweep will be done starting from the root.

So, this all comes down to the following piece of code then (slightly abbreviated):