JSF 2.3 wish list part I - Components

Over the last days several Java EE specs have published JSR proposals for their next versions. Today JSF published its proposal on the JSF mailing list, titled: Let's get started on JSF 2.3

The JSR groups improvements into 4 categories:

• Small scale new features
• Community driven improvements
• Platform integration
• Action oriented MVC support

An interesting aspect is the "Community driven improvements", which means it's basically up to the community what will be done exactly. In practice this mostly boils down to issues that have been entered into the JSF issue tracker. It's remarkable how many community filed issues JSF has compared to several other Java EE specs; clearly JSF always has been a spec that's very much community driven. At ZEEF.com we're more than happy to take advantage of this opportunity and contribute whatever we can to JSF 2.3.

Taking a look at this existing issue tracker we see there are quite a lot of ideas indeed. So what should the community driven improvements focus on? Improving JSF's core strengths further, adding more features, incorporating ideas of other frameworks, clarifying/fixing edge cases, performance? All in all there's quite a lot that can be done, but there's as always only a limited amount of resources available so choices have to be made.

One thing that JSF has been working towards is pushing away functionality that became available in the larger Java EE platform, therefore positioning itself more as the default MVC framework in Java EE and less as an out of the box standalone MVC framework for Tomcat et al. Examples are ditching its own managed bean model, its own DI system, and its own expression language. Pushing away these concerns means more of the available resources can be spend on things that are truly unique to JSF.

Important key areas of JSF for which there are currently more than a few issues in the tracker are the following:

• Components
• Component iteration
• State
• AJAX

In this article I'll look at the issues related to components. The other key areas will be investigated in follow-up articles.

Components

While JSF is about more than just components, and it's certainly not idiomatic JSF to have a page consisting solely out of components, arguably the component model is still one of JSF's most defining features. Historically components were curiously tedious to create in JSF, but in current versions creating a basic component is pretty straightforward.

The simplification efforts should however not stop here as there's still more to be done. As shown in the above reference, there's e.g. still the required family override, which for most simple use cases doesn't make much sense to provide. This is captured by the following existing issues:

• Add default implementation for UIComponent#getFamily()
• Clarify meaning of null return from UIComponent.getFamily()
• UIComponent.getFamily() not clearly specified

A more profound task is to increase the usage of annotations for components in order to make a more "component centric" programming model possible. This means that the programmer works more from the point of view of a component, and threats the component as a more "active thing" instead of something that's passively defined in XML files and assembled by the framework.

For this at least the component's attributes should be declared via annotations, making it no longer "required" to do a tedious registration of those in a taglib.xml file. Note that this registration is currently not technically required, but without it tools like a Facelet editor won't be able to do any autocompletion, so in practice people mostly define them anyway.

Besides simply mimicking the limited expressiveness for declaring attributes that's now available in taglib.xml files, some additional features would be really welcome. E.g. the ability to declare whether an attribute is required, its range of valid values and more advanced things like declaring that an attribute is an "output variable" (like the "var" attribute of a data table).

A nonsensical component to illustrate some of the ideas:

@FacesComponent
public class CustomComponent extends UIComponentBase {
 
    @Attribute
    @NotNull
    private ComponentAttribute<String> value;

    @Attribute
    @Min(3)
    private int dots;

    @Attribute(type=out)
    @RequestScoped
    private String var;
    
    private String theDots;

    @PostConstruct
    public void init() {
        theDots = createDots(dots);
    }
    
 
    @Override
    public void encodeBegin(FacesContext context) throws IOException { 
        ResponseWriter writer = context.getResponseWriter();
        writer.write(value.getValue().toUpperCase());
        writer.write(theDots);

        if (var != null) {
            getRequestParameterMap().put(var, theDots);
        }
    }
}

In the above example there are 4 instance variables, of which 3 are component attributes and marked with @Attribute. These last 3 could be recognized by tooling to perform auto-completion in e.g. tags associated with this component. Constraints on the attributes could be expressed via Bean Validation, which can then partially be processed by tooling as well.

Attribute value in the example above has as type ComponentAttribute, which could be a relatively simple wrapper around a component's existing attributes collection (obtainable via getAttributes()). The reason this should not directly be a String is that it can now be transparently backed by a deferred value expression (a binding that is lazily resolved when its value is obtained). Types like ComponentAttribute shouldn't be required when the component designer only wants to accept literals or immediate expressions. We see this happening for the dots and var attributes.

Finally, the example does away with declaring an explicit name for the component. In a fully annotation centric workflow a component name (which is typically used to refer to it in XML files) doesn't have as much use. A default name (e.g. the fully qualified class name, which is what we always use in OmniFaces for components anyway) would probably be best.

This is captured by the following issues:

• Declaring component attributes via annotations
• Extend facelet-taglib schema
• Provide mechanism for component to declare scoped variables
• Add annotations for Facelet artifacts
• Add @AjaxResource to simplify use of the standard Ajax resource

Creating components is one thing, but the ease with which existing components can be customized is just as important or perhaps even more important. With all the moving parts that components had in the past this was never really simple. With components themselves being simplified, customizing existing ones could be simplified as well but here too there's more to be done. For instance, often times a user only knows a component by its tag and sees this as the entry point to override something. Internally however there's still the component name, the component class, the renderer name and the renderer class. Either of these can be problematic, but particularly the renderer class can be difficult to obtain.

E.g. suppose the user did get as far as finding out that <h:outputText> is the tag for component javax.faces.component.html.HtmlOutputText. This however uses a renderer named javax.faces.Text as shown by the following code fragment:

public class HtmlOutputText extends javax.faces.component.UIOutput {

    public HtmlOutputText() {
        setRendererType("javax.faces.Text");
    }

    public static final String COMPONENT_TYPE = "javax.faces.HtmlOutputText";

How does the user find out which renderer is associated with javax.faces.Text? And why is the component name javax.faces.HtmlOutputText as opposed to its fully qualified classname javax.faces.component.html.HtmlOutputText? To make matters somewhat worse, when we want to override the renderer of an component but keep its existing tag, we also have the find out the render-kit-id. (it's a question whether the advantages that all these indirection names offer really outweigh the extra complexity users have to deal with)

For creating components we can if we want ignore these things, but if we customize an existing component we often can't. Tooling may help us to discover those names, but in absence of such tools and/or to reduce our dependencies on them JSF could optionally just let us specify more visible things like the tag name instead.

This is captured by the following issues:

• Simplify overriding a component's renderer
• Use a custom renderer on a composite component
• Make it possible to ask a Renderer for its family and renderer-type

Although strictly speaking not part of the component model itself, one other issue is the ease with which a set of components can easily be grouped together. There's the composite component for that, but this has as a side-effect that a new component is created that has the set of components as its children. This doesn't work for those situations where the group of components is to be put inside a parent component that does something directly based on its children (like h:panelGrid). There's the Facelet tag for this, but it still has the somewhat old fashioned requirements of XML registrations. JSF could simplify this by giving a Facelet tag the same conveniences as were introduced for composite components. Another option might be the introduction of some kind of visit hint, via which things like a panel grid could be requested to look at the children of some component instead of that component itself. This could be handy to give composite components some of the power for which a Facelet tag is needed now.

This is partially captured by the following issues:

• CC-like conveniences for Facelet tags
• Automatically discover *taglib.xml in META-INF

Finally there's an assortment of other issues on the tracker that aim to simplify working with components or make the model more powerful. For instance there's still come confusion about the encodeBegin(), encodeChildren(), encodeEnd() methods vs the newer encodeAll() in UIComponent. Also, dynamic manipulation of the component tree (fairly typical in various other frameworks that have a component or element tree) is still not entirely clear. As it appears, such modification is safe to do during the preRenderView event, but this fact is not immediately obvious and the current 2.2 spec doesn't mention it. Furthermore even if it's clear for someone that manipulation has to happen during this event, then the code to register for this event and handle it is still a bit tedious (see previous link).

Something annotation based may again be used to simplify matters, e.g.:

@FacesComponent
public class CustomComponent extends UIComponentBase {
 
    @PreRenderView // or @ModifyComponentTree as alias event
    public void init() {
        this.getParent().getChildren().add(...);
    }
}

This and some other things are captured by the following issues:

• Clarify UIComponent.encodeAll requirements
• How does JSF handle children when they are not JSF components?
• Explicit support for dynamic component tree manipulation
• Component context management
• InitialStateEvent is not fired from the ComponentHandler
• General purpose component metadata
• Add interfaces to javax.faces.component package

That's it for now. Stay tuned for the next part that will take a look at component iteration (UIData, UIRepeat, etc).

Arjan Tijms