Having been recently thrown into the deep waters of JSF and Facelets it seemed natural to do an evaluation of where this technology is going. JSF is currently at version 1.2. Version 2.0 is scheduled for release with Java EE 6. So what goodies will this bring us?
The main goals of the revision is to make development easier by integrating into the core system many tools/frameworks which were built on top of previous JSF versions. Ajax support, facelets-like templating, improved development support and better performance are all things that are mentioned in the specifications.
These are the highlights of what is coming:
- AJAX support
- Resource Handling
- ProjectStage parameter
- Page Definition Language
- more fun things to be found at http://www.jcp.org/en/jsr/detail?id=314
I’m sure everyone is familiar with Ajax. JSF 2.0 includes Ajax in its life cycle and offers more direct support for its use. The view state can now be partially updated to reflect that only part of the view has changed. Ajax will make use of the new resource handler scheme. This isn’t very exciting in and of itself. A natural progression in the way one would expect this technology to mature.
Facelets is another technology needing to be incorporated into 2.0. Facelets allows us to define our pages in a different way by using XML and templating. The way to write these pages is very close to the the way we already work, which makes it easy to learn. The added usefulness of templating allows us to write less cluttered pages. It also increases code reuse. The popularity of this approach and its obvious usefulness make it inevitable that this would be included in JSF 2.0. This is currently referred to as ‘page description language’ in the JSF specification. While the name is less exciting than Facelets it is accurate and there is no doubt that this is a welcome addition to JSF
Development for JSF is getting some support through the ‘Project_Stage’ feature. This is no more or less than a context parameter. Now many people are excited by this, but I don’t quite seem to share the sentiment. Theoretically this will allow for actions dependent on where the project is in its life. Is it in production, unit test, system test or development? The options are limited, though probably enough. What I am wondering is what it is doing in JSF. While there is a use for a setting like this, indeed it seems common in many disparate projects, it seems to me to be a higher level setting than JSF level. JSF should support it, but not claim it.
There are some things about resources I don’t like however. First of all the specification only specifies a structure for webapps. Implementations for other platforms are even invited to do whatever they want. It seems an unfortunate choice since you really want a standard to be standard. Another is the relocatable resource. Now you can tell certain resources where they are supposed to be. Put the tag in the body but tell it to be rendered in the head. I don’t understand the reasoning for this. Perhaps if it is based on some conditional programming elsewhere on the page….but quite frankly your page is probably getting to complicated at that point. If something needs to be in the head (body, wherever), just put it there. I wonder if I am not missing some essential insight with which I will all of a sudden see what a great and useful feature this is.
One argument for relocatable resource is that components may wish to write things in locations which are outside of their direct knowledge. The head of an HTML document is an example. A component, possibly called by other components, could decide it wanted to change the head of a document. This is completely undesirable behavior. If the component is generic it should never bother with anything outside its scope. If it isn’t generic then its use is limited anyway and one could ask why it is even a component. Thinking specifically of style information I would say that this should never be overwritten at component level. Scripts can be included in the body and shouldn’t require anything beyond what exists in the component anyway. Apparently the community desires this functionality. To me it seems a harmful construct which should not be supported.
All in all I think JSF 2.0 will be an improvement of the technology. It has listened and learned from what the community has built on top of JSF and incorporated the features that were most used. As well it improves its internal workings which is never a bad thing from a user perspective. While I may not yet understand all the choices made it is obvious that the changes were well thought out and planned. Assuming the implementation is improved as well then JSF 2.0 will be pretty much what you want from version 2.0.