JSR 314 - JavaServerFaces 2.0 is in the JSR review ballot phase. Check out the details at http://jcp.org/en/jsr/detail?id=314. However, the news is not really that new as conversation about JSF 2.0 was initiated by Ed Burns quite a few months back. For those of you who read his blog, you would be familiar with the JSF 2.0 requirements scratchpad. More recently he summarized the discussions at the JSF EG kick off meeting during JavaOne. Its available online again at Ed’s blog.
All in all, the start looks very promising. By next year when the specification is ready for release we would see a lot of goodies in JSF, some of them being -
- better view decription technology - somewhat like facelets or maybe better.
- application modification and deployment at runtime
- tighter integration with Ajax. perhaps support for a small JavaScript library contract specification.
- better and maybe centralized error handling
- minimization of “xml hell”, use of annotations instead
- possibility of RESTful urls and use of GETs
- skinning and themeing
- reduction of effort required for creating custom components
More details can be obtained from the sources mentioned above.
So all this good. However, I thought it was perhaps also time when one needs to look at the following -
1. unification of the client-centric and server-centric UI models, especially when they pertain to the same programming language. There is no stopping somebody mashing up the JSF lifecycle with a Swing Client but it is ugly and non-standard. How about creating standard hooks?
2. merging managed beans jsr with this one. Somebody in the JCP needs to start merging the JSRs. Of late there is a proliferation of these and at the rate it is going I wouldn’t be surprised if somebody started a JSR to reduce JSRs
3. portal is passe, if not it surely will die sooner rather than later. The client centric webos/webdesktop is gathering momentum. How about jsf taking the lead to include portlets within the realm of components and containers.
4. jsf, like everything web development java on the server side is based on the servlet API, which itself needs some rehaul, considering that it is purely server centric and quite inadequate in a newly evolving peer-to-peer world. Shouldn’t servlets and jsf evolve concurrently so that we could avoid some retrofitting.
5. Last but not the least, what about applications without servers - which go under the name of mashups often. which java web technology is good for it?
Here? Here?
I say till we have it supported on all containers/tools its gonna be 2009.
Widely used will be 2011.
If it gets widely used.
NEXT YEAR!? What takes these guys so long?
It's going to take sun until next year just to get the spec correct, then a few more months to a year for the implementations to be ironed, then the "tools/ide" a while to adopt so there is a point to even use JSF.... .
Too little too late I say. The java world won't care then, because it really doesn't care much now.
I'd like to see in JSF the ability to use EL expressions natuaraly int HTML tags. For example:
#{MyBean.name}
I'm working on some projects involving JSF and we found ourselves in the position of building custom components for html, head, meta etc. The reason is that we want to provide dynamic values to these tags attributes but in the same time to avoid JSP style for adding Java code () as this becomes in time a Pandora box. Once you use it, next developers maintaining the code will add crappy Java code in JSP making it a total mess.
for Marius: just use Facelets..and look around more next time ;)