Proposed enhancements to JSF 2.1

This page consists of an agenda and proposals put forth by Red Hat and its community for the JSF 2.1 specification . It's a continuation/overflow of the recommendations that were made for the JSF 2.0 specification.

Please also see the proposed changes for the EL 2.1 specification.

The page is divided into major and minor issues. Major issues are accompanied by a formal proposal. Both types cite references to a report in the JavaServer Faces specification issue tracker.

Table of contents

• View actions (P0)
• Default application time zone (P1)
• Generic Subtree validation (P2)
• Multi-component validation using Bean Validation (P2)
• Support for Collection interface in UIData (P0)
• Prevent Facelets from eating whitespace (P1)
• Declarative navigation for exception handling (P2)
• Reevaluate component referencing mechanisms (P2)
• Rendered is ridiculous (P2)
• XSD for Facelets (P2)
• Minor issues

Major issues

A priority grouped list of major issues that are accompanies by formal proposals and may require further design and discussion.

View actions (P0)

To allow JSF to fit better alongside action-oriented frameworks (and existing applications that use them), we propose the addition of view actions. View actions are the compliment of a UICommand for an initial (non-faces) request. View actions accommodate scenarios such as registration confirmation links, security and sanity checking for a request (e.g., valid resource identifier).

Design

Refer to the JSF enhancement: View actions page.

Spec issue reports

• 758 - Support view actions
• 488 - Enhanced life cycle for NonFaces requests (issue now closed)

Default application time zone (P1)

Time zone handling has always been a pain point of JSF. To be specific, it's the time zone offset used when displaying a time (or datetime) using JSF that's troublesome. Storage of times is typically assumed to be relative to UTC.

The issue is that time zones are very much a user setting, not a system setting. Yet the only control mechanisms in JSF related to time zones are to adjust the default time zone used by the application. We would like to explore the possibility of making the time zone a dynamic binding that can be fulfilled by a managed bean that reflects the user's setting.

Design

See the JSF Enhancement: Default application time zone page.

Generic subtree validation (P2)

The idea of applying a validator to an entire subtree of the JSF UI component tree was prototyped in JSF 2.0 via the Bean Validation integration. We would like to make the ability to apply a validator to a subtree applicable to all validator tags.

Remarks

The implementation of this generic proposal should replace the partial solution that currently exists to support the BeanValidator requirements.

Spec issue reports

• 481 - Validate entire subtrees

Multi-component validation using Bean Validation (P2)

The biggest pain point in JSF is arguably the lack of support for multi-component (or inter-component) validation. It's easy enough to apply a validator to a single component. But when the value of a related component is needed in order to validate the current component, the JSF validation model breaks down. As a result, the developer has to implement a custom solution (and quite a lot of code) to get it to work.

Use cases

An example of multi-component validation is validating a credit card number based on the credit card type, validating a car model based on it's make, or validating that one date precedes or follows another date.

Spec issue reports

• 1 - Multi-component validation

Support for Collection interface in UIData (P0)

Currently the UIData and UIRepeat components narrowly support java.util.List rather than the more generalized java.util.Collection. This behavior is extremely inconvenience since the interface java.util.Set is prevalent in JPA entity classes, a central component in most enterprise web applications. This forces the developer to have to constantly wrap the sets as lists using various creative approaches.

History

This issue was raised by both Adam Winer a while back. He presents a rather obscure solution in this entry, though one that likely many developers use out of necessity:

• Using Sets with UIData

Implications

But what about the point that a Collection is not indexed by definition? Up to this point, all collection types that JSF supported have been indexed collections. There are two issues to address when introducing support for a non-index collection:

• Accessing the collection by index
• Consistency in ordering between iterations

The first is a concern of the implementation and the second a developer concern. In order to iterate a Collection that is not a List, we have to keep an internal List. Doing that has an important side effect (which is not negative, just different). The result of getWrappedData() is not going to be the original collection. It's either an abstract collection with a shared iterator or a copy.

The ordering is a concern of the developer feeding the collection into the UIData or UIRepeat. Maybe the developer doesn't care that each time it iterates, the order is different. Maybe the developer is using an ordered but not indexed collection such as a LinkedHashSet or a TreeSet. The point is, UIData and UIRepeat should be able to iterate a basic java.util.Collection.

Spec issue reports

• 479 - UIData should support Collection

Prevent Facelets from eating whitespace (P1)

Facelets eats whitespace. When two components have only whitespace separating them, Facelets will trim that space so that the output of the two components are mashed together. You see this most often with links.

<h:commandLink value="Link 1"/>
<h:commandLink value="Link 2"/>

Here's what the rendered output looks like to a user:

Link 1Link 2

To get around the problem, you can place a value expression that produces a UIOutput component whose value is a space between them:

<h:commandLink value="Link 1"/>
#{’ ‘}
<h:commandLink value="Link 2"/>

This is super hackish. One way to fix Facelets is to remove the logic in the TextUnit#trimRight(String) method, which cuts out what Facelets perceives to be non-semantic whitespace.

The main reason that Facelets trims is to prevent creating components to represent the whitespace. One area in particular where this is an issue is a panel group. Consider:

<h:panelGrid>
   <h:outputText ... />
   <h:outputText .../>
</h:panelGrid>

In this scenario, the intention is to create a two column table to encapsulate the two outputs, but if there is trailing whitespace after either of the output text fields, you end up with a three column table because the whitespace wasn't trimmed and Facelets generated a component for it.

Frankly, I don't give a damn. In my mind, Facelets is broken. I have been hammered on this issue more times than I care to say. Mangers question why I would chose a technology that does such a silly thing. We need to resolve this one way or another because we can't go forward with status quo.

One solution is to have a trimming setting per component which determines whether whitespace is trimmed in the component's direct decedents. This should likely be part of the component metadata.

Spec issue reports

• 332 - Don't trim whitespace in literal text

Declarative navigation for exception handling (P2)

JSF 2.0 introduced a new exception handling mechanism which queues unexpected exceptions and passes them to the registered ExceptionHandler. The default implementation wraps the root exception in a ServletException, allowing the developer to use the <error-page> directive in web.xml to associate an error page with a given exception class. But the servlet exception handler operates outside of the JSF life cycle, which is often inappropriate for dealing with exceptions that originate from within the JSF application.

Seam's pages descriptor has a section which allows a developer to associate an exception with a navigation rule. We would like to bring this feature to JSF 2.1 so that the exception can be handled within the boundaries of the JSF life cycle. Leveraging the JSF ExceptionHandler to deal with the exception makes it possible to do things like navigation to a view ID (rather than a servlet path), add a faces message to the request, append redirect parameters and/or log a message, all through configuration.

Spec issue reports

PENDING

Reevaluate component referencing mechanism (P2)

There are several features in JSF which require one component to reference another component. There are slight variations in the algorithm used to find the related component between implementations, exposing the fact that a spec clarification is needed. In addition, there are two other concerns to address: usability and performance. We would like to find a flexible syntax with a consistent interpretation for component referencing.

Spec issue reports

PENDING

Design

See the JSF Enhancement: Component referencing page.

Spec issue reports

• 332 - h:message for attribute is mis-specified

Rendered is ridiculous (P2)

The rendered attribute is an Achilles heal of JSF performance. JSF abuses the value expression used in rendered attributes. It's expected that the value expression is going to be resolved more than once on a request because by nature it is a pass-through construct and because the value it is representing is likely contextual (meaning it can change as the application changes). However, in the case of the render attribute, it's a little bit out of control. Any getter method bound to a rendered attribute is being called way too many times. This could easily be solved by being more frugal about when it is consulted.

For example, the rendered value expression is resolved in encodeChildren, encodeBegin (or encodeParentAndChildren) and again at encodeEnd of most components. We should state that when a component is first addressed during encoding (perhaps in encodeBegin) that is when the rendered attribute should be evaluated. Then the resolved value simply cannot change again in that phase. (The exception would be a row in UIData, which the rendered attribute would need to be resolved once per component per row).

The point is that the isRendered() method should be smarter than just evaluating the EL every single time it is called. It should do a rendered check only in encodeBegin. Such a solution only affect a small part of the problem though. For one it only partially fix the issue for a single attribute (rendered) since it saves 2 evaluations out of 3 during render response which is nice when it's a GET request (66% improvement), but much less important during postbacks where it's only going to save 2 evaluations out of 7 (28% improvement).

We should also consider having encodeAll check the rendered attribute and not encodeBegin. Or, we could keep the current contract the same but deprecate encodeBegin, encodeChildren, encodeEnd and getRendersChildren so that most people start using encodeAll instead so that isRendered gets called only once per component per render phase execution.

Spec issue reports

• 1253 - reduce number of times rendered attribute value expression is evaluated

XSD for Facelets (P2)

See the entry It's time for Facelets to start using XSD for background and a sample implementation. Review the issue reports for the details of what's being requested, including the possibility of a different file extension.

Spec issue reports

• 489 - Use XML Schema as the TLD language
• 490 - Default template file extension

Minor Issues

These are issues which don't require much or any design work.

• Loosen the rules for property setter methods; a setter should be defined as a single argument method whose name is formed by capitalizing the property name and prepending set. The argument type must be assignable to the property's type, but there should be no restriction on return type (allow non-void return values to support the builder pattern).
• f:validate vs f:validateBean - What is the issue here?
• 494 - Default DateTimeConverter should be registered to registered for java.util.Date type
• ISSUE REPORT NEEDED DataModel should implement Serializable
• ISSUE REPORT NEEDED Support nested path/directory structure for resource locations. In JSF 2.0 all resources must be at one level.
• ISSUE REPORT NEEDED Better nested path/directory support for composite component files. Currently this is only supported by specifically setting configuration settings in a <facelets-taglib> file. This path could easily be determined from the namespace.
• 728 - Allow control over whether an empty string is treated as null per UIInput, potentially overriding the application-wide setting
• ISSUE REPORT NEEDED Aggregate UI component tags under a common namespace if the namespace is declared in multiple taglib.xml files.
• 329 - A radio button component that allows buttons to be placed arbitrarily in the layout
• JSF should consult the existing id attribute on the root element (<faces-config>) of faces-config.xml when looking for a name to assign to the faces-config.xml. Currently, JSF uses the contents of the child element <name>, but this isn't backwards compatible. Names are used for ordering.

Key

• P0 - critical: a problem directly affecting Seam or RichFaces
• P1 - top priority: problem must be solved for the specification to be a success
• P2 - middle priority: problem should be solved if EG agrees and high priority items are addressed
• P3 - low priority: a solution would be nice to have

Sources of ideas

• JSF 2.0 ideas
• Usability problems in JSF
• Pete's rough sketches for JSF 2: part 1, part 2
• Gavin's EE 6 wishlist (JSF)
• A wicket user tries JSF - Mostly a flame war, but some good ideas reside in the comments
• JSF 2 MR1 Agenda