Link Details

We all enjoy standing around the water cooler and complaining about the Java EE specifications and speculating how out of touch the EG is with reality. Now is the opportunity to be a constructive member of the Java EE community and actually do something about it. The Seam project members, and RedHat in general, recognize that like it or hate it, the Java EE platform is what we have committed ourselves to, our "home country" if you will. So they are carefully documenting the pains that exist in JSF so that the same mistakes are not made again (or allowed to persist). I encourage you to read through these concerns and raise points that you feel are not being addressed here to the Seam project members (specifically Pete Muir, the team lead).

Some of you have no interest in JSF, and that's fine. For those who believe in it or want to see it fit the expectations you have for it, study this page and make a difference.

That is a massive list of issues, As I said, JSF is a piece of garbage over-engineered, Better use Wicket and Seam now supports Wicket.

JSF provides a good basis, but if you really want an end-to-end solution then you want a JSF based framework.
Oracle ADF for example extends JSF and provides: templating, Declarative JSF component creation, over 150 Ajax enabled components, New memory scope for processes, reusable flows, extend flow definition that includes calling to methods and switchers, bookmark support and more.
What the JSF EG needs to do next is pick up these type of innovations and bring them into the JSF standard.
,

I don't necessarily agree that JSF should contain the kitchen sink. It needs to be partitioned correctly. For instance, in JSF 2.0 they are going to introduce the view scope, which is the same as Seam's page scope (it stores data in the component tree). But a conversation-scope, for instance, would not be appropriate in JSF because that is something that WebBeans needs to provide. You could probably argue that pageflows belong in JSF, but don't expect that until after 2.0.

And no, I don't necessarily agree either that the 150 Ajax-enabled components should be part of JSF. JSF is a foundation layer on which component libraries can be built. What is important is that this foundation layer provide an Ajax-bridge that can be shared by multiple component libraries (this is the reason that RichFaces and ICEfaces don't mix well today). JSF is incorporating Facelets as a standard, so there is your templating framework and simple component creation. But of course you are going to want to have a component library to use with JSF. That is the entire philosophy of the framework.

JSF is not over-engineered, it just was a bit premature. Wicket has its own share of issues, as does every framework. What matters is that we use our heads and make the Java EE platform better.

>> We all enjoy standing around the water cooler and complaining about the
>> Java EE specifications and speculating how out of touch the EG is with reality.
>> Now is the opportunity to be a constructive member of the Java EE community
>> and actually do something about it.

Sorry. Life is too short and I prefer to spend time being intensely productive with a Java EE compatible framework like Wicket which is available *now*, is mature, supports Ajax brilliantly and has none of the limitations of JSF.

At least it is very promising that the expert group is very aware of the current problems.