Thoughts on JSF 2.0 Draft

The ball has started rolling for JSF 2.0 - and it looks like there are going to be some big changes!

JSF has had a very mixed reaction from the community. It's overwhelming strength is the ease with which you can build a whole new component set (and easily render to non-web media like Email, PDF...); in theory, you can just drop in a whole new set of components in 20 minutes.

One of the big issues currently is that it needs soooo much wiring - to write a tag you write the component class, add it to faces-config.xml (with all its properties), add it to your.taglib.xml, write a Tag class (with all it's properties) and add it to your tld (with all its properties),. You then have to write your state saving manually, and make each property read both a static and EL resolvable variable. Tools like Ajax4jsf's CDK take some of the pain out of this, but annotations would be much neater :)

So, whats hot and whats not in the draft?

Theming/Skinning - this one is SOOO important - one of the things that always makes me go "oh, wow" about a Mac is that it looks pretty. Currently there are themes/skins for most component sets - so that using e.g. Trinidad and RichFaces together looks nasty, without considerable CSS hacking.

A new JSF version should make it really easy to apply the same skin to all the component sets (at least for the standard components) and have them come out looking the same - of course you would still need to skin non-standard components!

AJAX and REST - support for working on refreshing/restoring part of the tree is probably the largest new proposal for me, only matched making JSF restful where possible.

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)

JSF should look at providing restful access to dynamic resources (e.g. images stored in databases) - after all JSF is (at least currently) mainly used in applications, not websites, which deal mainly with dynamic data! I've got some ideas about how to do this which I'm going to put into s:graphicImage soon :)

Components - I've got mixed feelings about adding more components to JSF - this is what some components sets do so well.

I think the API should define some optional components - define the component model but not require a renderer for that as part of the implementation. In this scenario, for example, MyFaces Core could implement the core spec, and then you could choose a component set for the optional bits (IceFaces, Trinidad etc.). To me, some of those components seem pretty heavy weight for the default impl - captcha for example

It's in there, but not explicitly - strong support for annotations for defining a component and building the necessary wiring e.g. so you can just do @Property(el=true, saveState=true), or @Validator...

Use generics in validators and converters - very minor, but would save a few casts!

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.

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'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!

Something I've needed is the ability to apply multiple converters to a single component. You need a way of defining the order in which the converters are run, a notion of a successful conversion (sometimes it's not possible for a converter to do it's job), and whether to keep running the chain if conversion is successful.

Exception Handling - better exception handling is definitely needed, but shouldn't be limited to a default mechanism - what's needed is a pluggable exception handler so that an application can define a centralised exception configuration that deals with persistence, business AND UI.

JAR Layout - the idea of a location convention (i.e. all converters in in war/converters/seam-converters.jar) is interesting - but surely if all you need to do to make a class a converter is do @Converter, @ConvertToString, @ConvertToObject (or something)... or have I missed a point here?

Minor - Page actions would be great, and make it easier to migrate from other platforms

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!

Perhaps a more flexible ExternalContext - allow you to render programmatically as well as to a responsewriter

Pluggability - 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.

Performance - this all looks great!

So, all in all, its looking pretty good!