Monday, February 06, 2006

What belongs in the JSF standard?

As the Expert Group starts working on JSF 2.0, we're faced with a very fundamental question: how do we pick and choose what belongs in the standard? And what, by contrast, does not belong in the standard?

There are several reasons why something should go in the standard:

  1. Feature ABC cannot be implemented outside of the standard.

  2. Feature DEF is not directly needed by the standard, but promotes interoperability.

  3. Standards receive better tool support, and tool support is essential for feature XYZ.

Some examples of each:

  1. JSF Avatar requires support from UIComponent, and therefore has to go into the standard.

  2. The DataModel API allows interoperability between different model providers and component providers. It would be helpful if JSF had a TreeModel for the same reason - instead of everyone inventing their own TreeModel, we can have one abstract interface that lets model experts provide the best implementations possible and component developers design the best tree UIs around.

  3. Facelets would benefit from tool support (Creator, JDeveloper, etc.)

But if you don't meet these standards, why not still add the feature to JSF? Why not add a calendar component? How about a declarative framework that makes it easy to create renderers? Or support for XSLT post-processing of content? These all seem like handy features, but I feel strongly that none belong in the JSF standard yet. A J2EE standard has very difficult constraints placed on it. The long development cycle means we only get to add features occasionally. But we're also required to maintain backwards compatibility, so fixing mistakes is difficult-to-impossible. So, here's a list of some reasons why not to add something to the JSF spec:

  1. Feature ABC can be implemented just as easily outside of the spec as inside of it. That is, the current public API is entirely sufficient to implement the feature.

  2. Feature DEF is not yet well understood - there are multiple possible directions to head. The JCP process works best when it standardizes existing best practices.

  3. Feature XYZ is of only limited use - not everyone needs it.

These are not at all mutually exclusive lists. For example, the Avatar API is not the last word in handling AJAX requests for JSF. A declarative framework for renderers can be implemented outside the spec, but it would benefit from more tool support. And so forth.

Perhaps the most difficult task of any framework developer is learning how to say "No". As in, "No, we don't want that feature." But that is absolutely our responsibility as architects of JSF.

It's down there somewhere, let me take another look...
-- The Big Lebowski


Post a Comment

Links to this post:

Create a Link

<< Home