Major issues

A priority grouped list of more major issues that require extensive design and discussion:

Easy Component Creation, standardization of Facelets, Simple development of JSF UIComponents (P1)

(In progress)

It needs to be easy to create register new components written in Java, preferably through annotations

JSF needs its own templating language. Facelets is the perfect starting point. Support for JSP should be deprecated.

It's lucky that there are so many JSF component libraries out there, since developing controls yourself is a huge pain. The biggest problem is JSP, so introducing a standard JSF-specific template language should improve the situation dramatically and make JSF UI component development much more accessible to regular users. The template language could also make it easy to define components which are composed of other components, just like Facelets does today.

Issues:

• 287 - Defining components via annotations umbrella issue
• 274 - PDL Umbrella issue
• 280 - Declarative PDL renderers

View Syntax (P1)

First and foremost, the preferred view syntax should be 100% valid XML and not some pseudo-XML that JSP let in the door. Going beyond basic XML syntax, standard and custom tags should be described using XML Schema, not another proprietary tag descriptor language (TLD). Nearly every XML editor on the planet understands, supports, and can provide tag completion with documentation for the XML document when an XML Schema is associated with it.

XML Schema also has the most advanced facility for describing the valid syntax for an element or attribute (permitted child elements, presence of EL expressions, etc). By standardizing on XML Schema, which itself is a W3C standard, developers don't have to wait for vendors to create tooling for basic XML editing capabilities. Also, developers have become very used to XML schema with it being supported in the Seam component and pages descriptor and Spring and Spring Web Flow configuration files.

In summary, importing a custom tag into a view template would involve defining an XML namespace and optionally (though preferably) associating that namespace with an XML schema document. Component libraries would be required to provide this XML Schema document (perhaps generated; and yes, it is worth doing!). Also, view templates should use the file extension .xml and not try to pretend like it is XHTML by using the .xhtml extension. A longer suffix like .view.xml might be even better. Thus, a view ID would be users.view.xml.

AJAX (P1)

(In progress)

Issues:

Pluggability (P1)

This is a meta issue

One of JSF's key strengths is the ability to easily swap out bits (e.g. the EL resolver, the navigation handler, even the Application. This needs to continue and be made stronger in JSF 2.0

For example, passing values from page-to-page could be good, but, if you are using another framework like Seam, you might want to swap out the implementation for your own. Another example is that the spec proposes solving the concurrent/lost submit problem - again, any solution MUST be pluggable.

Exception/Error Handling (P1)

(In progress)

JSF's lack of facilities for exception handling is a major embarrassment, and totally ignorant of current best practices for exception handling in Java. It is impossible to do any centralized handling of exceptions without writing a servlet filter. Specifically, JSF should provide a declarative exception handling facility, and in addition provide a way for an application/framework developer to register an exception handler class for more control.

Even worse than the lack of exception handling in JSF, Unified EL has the totally pathological behaviour of wrapping all exceptions (even runtime exceptions) that occur during invocation of the managed beans in a totally useless ELEvaluationException. Both of these problems should be fixed.

Issues:

(P3) One very exciting and interesting solution to the first problem would be to redesign the JSF Lifecycle object using a chain-of-responsibility pattern. Each lifecycle phase would be an element of the chain and would be responsible for delegating to the next phase. The application would be able to add in new phases at any point in the chain, which would provide for the possibility of centralized exception handling via around-style interception. We could then deprecate the PhaseListener extension point which is useful but limited and inelegant. This approach would make JSF much more extensible.

Enhanced lifecycle for non-faces requests (P1)

JSF devotes much love and attention to the faces request lifecycle for JSF form submissions. It also talks briefly about something called a non-faces request. The most interesting kind of non-faces request is a HTTP GET request, which - when you think about it - is actually the most common kind of request. Here, the spec is a great disappointment. It's certainly possible to create bookmarkable JSF pages with request parameters, but you lose a level of abstraction, and end up writing servlet-like code.

Seam solves this problem by providing page actions and page parameters, which are similar to the abstractions provided for faces requests. (They also look a lot like the functionality provided by an action-based web framework such as Struts or WebWork.)

JSF 2.0 should define a lifecycle for non-faces requests that includes:

• validation and model update for request parameters

• some mechanism for handling validation failures

• action invocation (Discussion started)

• some facility to redirect the request to a different URL

In other words, non-faces requests are going to need to provide all the things that faces requests currently provide. The only difference being that the submitted values are not coming from JSF input components, but rather from plain HTTP parameters (in a bookmarkable URL, for example).

The interesting question is exactly where should these actions, the mapping of request parameters to model attributes and validation be declared. The solution provided by Seam today is to declare this in an XML document along with the orchestration logic (navigation). But I'm increasingly favorable to the idea of embedding this in the page definition. For example:

<f:view>
   <f:parameter name="customerName" value="#{customerFinder.name}" required="true">
      <f:validateLength max="100"/>
   </f:parameter>
   <f:onRender action="#{customerFinder.findByName}"/>
   ...
</f:view>

This ties into navigation controls and improvements to the navigation system

Improved orchestration and Navigation controls(P1)

JSF navigation rules provide the basic functionality you expect if you've ever used something like Struts or WebWork. You can write an action method which returns a String-valued outcome, and define navigation rules in XML that determine the view to be rendered or redirected to. The following improvements are sorely needed:

• Outcomes shouldn't need to be Strings - anything with a toString() method should work Done in JSF 1.2

• It's much more transparent and elegant if the action method does not need to return an outcome at all - instead, the navigation rule could specify a value expression to be evaluated

• Navigation rules which perform redirects should be able to specify a list of request parameters to use in the redirect (where the parameter values are defined using value expressions)

• Navigation rules should be able to specify a HTTP error code as the result Won't fix.

The following kind of thing would be possible:

<navigation-rule>
   <from-action>#{customerFinder.findByName}</from-action>
   <navigation-case>
      <if>#{customerFinder.result!=null}</if>
      <to-view-id>/displayCustomer.xhtml</to-view-id>
      <redirect>
         <parameter-name>customerId</parameter-name>
         <parameter-value>#{customerFinder.result.id}</parameter-value>
      </redirect>
   </navigation-case>
</navigation-rule>

(Seam provides all this functionality today by defining it's own XML-based language for navigation rules.)

JSF is currently missing navigation controls - you want to call an action or navigate to an outcome BUT you don't need to submit a form, and should be restful! Lots of toolkits have implemented these (e.g. Trinidad, Seam UI)

Issues:

• 454 - add <if /> element
• 484 - Parameters on redirect rules
• 170 - allow <f:param /> as a child of <h:commandButton />
• 179 - alterations to navigation handler API
• 487 - add navigation controls
• 359 - allow EL in <to-view-id />

Validation (P1)

The following proposals and discussions relate to improvements to the validation system. There are many styles of validation and these issues try to address poor assumptions made in JSF and ways to make validation more DRY.

Subtree validation (481)

Moved to Subtree validation on the JSF 2.1 page.

Inter-component validation

Inter-component validation is a big hole currently - it's fine to do more complex validations in the action method apart from the fact it means validation errors occur in two phases which is confusing for the user.

---

I (Dan) don't think that cross-field validation is a difficult problem to solve from the specification level. The reason cross-field validation is difficult today is because each field is converted individually, just prior to being validated. Therefore, when the validate() method is called on a UIInput component, there is no guarantee that any other component in the form will have been converted at that time. It depends on the relative placement of the components in the form, a fact which should not be relied on in a validator.

The current strategy puts the onus of having to convert the related field(s) on the validator that is attempting to perform a cross-field check. Naive developers will simply ignore the converters on that field. The developers that do use the proper converter logic may still get sloppy with exception handling. Refer to either the EqualityValidator in Seam or Tomahawk to witness the ridiculous amount of code that must be used to handle all of these concerns properly.

A better way to implement validation is to first convert all of the components in the form. Once all the conversions are complete, then the validators run. An extra walk of the component tree can be avoided by putting the input components that were converted into an ordered collection (or map) and then iterating over that collection (or map) to apply the validators. Using this suggested strategy, implementing a multi-component validator is no more difficult than implementing a validator on a single component. The validator tag would need to provide some way to declaratively refer to the related components, such as by ID or value expression.

Frankly, I don't feel it is the responsibility of the specification to create a multi-component validator solution. What the specification should do is make it easy to create such a solution. With that said, I do believe it would be a good idea to implement a couple of basic multi-component validators to demonstrate 1) how it's done and 2) the ease in which it can be done with conversion and validation happening in distinct steps. Reference validators would include an equality validator (one or more components), a greater and less than validator, and perhaps a switch validator (a boolean component toggles the required flag on another component).

---

I'm not a fan of client side validation - but I really like Ajax-style validation (use server side validation, and just re-render the relevant field). But if client-side validation was used where possible (e.g. required fields) and then Ajax was used if not possible, and the messages just completed as necessary this would be cool!

CRUD - Field decoration, validation and conversion - easy CRUD is certainly good, field decoration - like Trinidad's label, help and message placement BUT it should templatable (for example, Facelets ui:decorate) so that you can easily change the layout of the decoration.

Handling of JSF messages is also weak: A message is either global or bound to a particular component. On the view, you can show either all global messages or the message for a particular component. There is no way to say, convert a component-bound message to a global message. I should be able to display and bundle whatever messages I feel necessary to show in whatever location. What would really be cool is to be able to assign tags to a message so that it would be possible to group them by different aspects and possibility even use the same message in multiple places on the page by tag. Issues:

• 426 - Integration with Bean Validation
• 480 - Validate null fields
• 481 - Validate entire subtrees
• 482 - A default validator
• 483 - s:decorate

Alternative stateless UI component lifecycle and View Exipry (P1)

JSF's UI component tree is stateful, meaning that the tree of components is maintained across faces requests (form submissions). This is a nice feature that lets JSF handle forms with conditionally rendered and repeated inputs, and forms with components that are manipulated programmatically. However, in the simple (and common) case, statefulness is overkill. Most forms don't have conditionally rendered controls or grids of controls. JSF needs an alternative stateless lifecycle to deal with the common case.

One possible option would be to copy Tapestry. Tapestry distinguishes between simple forms (which have no repeated or conditional controls) and complex forms (which do). For simple forms, Tapestry uses a stateless lifecycle. For complex forms, Tapestry serializes some information about the component tree to and from the client, and uses this when reconstructing the component tree during the rewind phase. (The handling of complex forms in Tapestry is very conceptually similar to the stateful model used in JSF.)

Issues:

• 139 - Stateless lifecycle
• 272 - State management revision
• 476 - View expiry problems

Proper coverage of collections in UIData (P2)

The root of the Java collections class structure is java.util.Collection, yet this interface is not supported in the UIData family of components. Instead, developers are forced to use a List or wrap their collection in a custom DataModel implementation (which is what Seam does). The impedance mismatch is introduced by the fact that java.util.Set is likely the most common association mapping in ORM. Since the UIData model and ORM go hand-in-hand, there should be support for java.util.Set (and preferably java.util.Collection) in UIData. Granted, only a java.util.List can be accessed by index, which is why it would be acceptable to wrap any other collection in a List implementation internally. Basically, the developer should not have to care that they are creating a data table from a Set vs a List. This is an area where the JSF abstract just bleeds.

• 479 Collections in UIData

SelectItems (P2)

Move s:selectItems functionality into the spec and other minor selection enhancements

Related issues:

• 450 - Allow f:selectItems to reference any Collection or array (not just those of SelectItem)
• 451 - Support for a noSelection in h:select*
• 226 - Decoding of SelectOne
• 230 Native support for Collections

REST (P2)

The JSF2 expert group should work closely with the JSR 311 expert group to define overlapping integration points (unified configuration) and programming models, so that a JSF implementation can work seamlessly with a JAX-RS implementation. For example, a @Path annotated POJO should work as a JSF backing bean without any additional configuration. A JSF application programmer should be able to expose RESTful remote APIs easily.

Related Issues:

• 146 - Add a pathinfo handling & URL friendly state/param holding
• 485 - REST umbrella issue
• 487 - Integration with JAX-RS

Theming/Skinning (P3)

(IMO we are out of time to address this, so should be slipped)

Currently there are themes/skins for most component sets - so that using e.g. Trinidad and RichFaces together looks nasty, without considerable CSS hacking.

Issues:

• 316 - Skinning umbrella issue

Default Application Time Zone (P2)

Moved to Default application time zone on the JSF 2.1 page

---

Minor Issues

• (P1) 323 Empty fields are submitted as an empty string, not null. Default should be null, with an option to override. Workaround implemented in JSF, try to get it fixed in EL properly

• (P1) 428 - Deprecate required="true" in favour of proper validation

• (P1) Meta issue In general the proposed draft at times appears to be drifting from being a user interface orientated to addressing other problems (for example persistence integration) - sure, make integration possible or even easy, but don't spend too much time on this!

• (P1) 478 Rendered attribute is overloaded

• (P1) 161 Allow alteration of naming container separator character

• (P1) 475Ensure converters are run even if the value is null

• (P2) 456 saveAttachedState and restoreAttachedState should automatically iterate over any java.lang.Iterable and attach/restore the state of each item (currently it just does this for lists)

• (P2) 358 Amazing as it seems, JSF provides no API for invalidating the HTTPSession.

• (P2) 447 Make FacesEvent parameters optional

• (P2) 456 Native support for Collections

• (P3) 477There should be convenience methods to render a JSF view programmatically - this would set up the lifecycle and render the view - after all, you can easily use an alternative ResponseWriter to writer to a StringBuffer. We do this in Seam to allow you to send an email (templated using facelets) from your backing beans - but, unless the request originated in a JSF request (it might be from another source like an MDB, a timer), we have to create our own JSF context.

• (P3) 143 - Use generics in validators and converters - very minor, but would save a few casts!

• (P3) 457 Allow use of EL in messages - JSF's use of EL is a really strong point of the whole architecture. However, one minor thing is missing: messages defined in resource bundles and in FacesMessages should support interpolation of embedded value expressions. (Seam already supports this.)

• (P3) JSF doesn't provide any special functionality for authentication or authorization. I'm not sure what we should do here (if anything), but we need to at least discuss the problem. Spoke to Shane, no need for anything here

Key

• P1 - top priority, the problem must be solved for JSF 2 to be a success in our opinion
• P2 - middle priority, problem should be solved e.g. if other matters are more pressing or the EG is opposed to the idea
• P3 - low priority, would be nice to get a solution in

Links

• Ideas from Ed Burns
• Gavin's Blog