3
The JSF 2.0 Expert Group (operating under the auspices of JSR 314) has released Early Draft Review 1 of the upcoming revision of the spec. We are soliciting feedback, of course, and the window of opportunity for that runs through July 2. If you want to have some input on the direction of the specification, now is the time to speak up. 
The major
changes in this
release are Ajax support and
composite components.The major changes in this draft release are baked in Ajax support, and what we’ve termed “EZComp,” which is better described as composite components. Composite components, which touches on a change to finalized in a later release, namely, the inclusion of Facelets, allows a component developer to create a new component by piecing together several others in a template file. This functionality is very similar, as best as I can tell as I’ve never used them, to Facelets’ component support, where a snippet of markup is specified in a file and can then be treated as an actual component. Unlike the Facelets version, though, these composite components are “real” components in that they are backed by a UIComponent. If you were at JavaOne, this is what Ed demoed in this presentation (with Roger demonstrating the Ajax support).
There’s still much work to be done before September when we are schedule to deliver the Proposed Final Draft, but this is a pretty good start. If you have any interest at all, please review the spec and give us feedback. We really do want your input, as our goal is to improve upon the JSF experience and solve as many of the real world pain points as we can. If your favorite pain point isn’t being addressed, you owe it to yourself to speak up!
Technorati Tags: javaserver faces, jsf, jcp
Popularity: 73% [?]
Thanks for the update Jason. Maybe I’ll have to look into this JSF stuff.
June 3rd, 2008 | #
Les, it will change your life forever!
June 3rd, 2008 | #
This is the one of the best news to see good progress in JSF2.0.
It is good to see component authoring is in focus, I hope composite component pattern by just templating should be adopted from facelets asap.
I hope to see lot of annotations support in component authoring, so component authoring can be made easy.
Skinning part should also be part of the specs, so that components can look more rich.
Every component should have ajax support. Validation and messages should be client side + Server( AJAX).
Now I will go through spec and share my feedback.
JSF2.0 spec needs to be marketed and time to market is key.
With JBoss Rich Faces and Woodstock 4.3 I am very confident about JSF sucess.
June 3rd, 2008 | #
Rahul, as luck would have it, annotations will be tackled for the next part of our work.
The current plan is that just about everything that goes in faces-config.xml will have an annotation. Navigation is the only exception that comes to mind, but I might be wrong even about that one. We will also look at skinning, though that hasn’t even come up yet, so I don’t even have a vague idea what that might look like, assuming we get to it.
I have a list of what our plans are. I need to check to make sure I can post those, but, if I can, I’ll try to post it here as soon as I can.
June 3rd, 2008 | #
Messages are still server side component, even Validations that are done via AJAX cannot refresh them, JBOSS has this feature in Rich Faces.
Validations should also support client side validation model.
No mention of how JSF 2.0 is simplifying the component creation process ( annotations or something).
It is good to see AJAX specifications and Facelets official acceptance.
June 4th, 2008 | #
Most of the woodstock 4.3 components have DOJO support so can be accessed client side, same is also true for JBoss Rich faces 3.2.1(rich:componentControl).
Woodstock and JBoss rich faces 3.2.1 provide most of the good things for JSF and are acting as catalyst for JSF popularity.
Had anybody from JSF spec team seen JBoss CDK, this is something which can be reused in JSF 2.0 specs.
June 6th, 2008 | #
Hi, One question - What is your view on java beans getting converted by JSF framework into JSON objects and then components can focus more functionality on client side.
Currently their is also some work happening in Majorra Scales, what is this exactly and how will it benefit JSF community, can u point me to some good documentation if it exist or better write few more lines here itself.
Basically framework should have capability to convert Manged Bean logic into javascript (GWT), so that maximum possible user interaction is handeled at client-side.
I hope I am making sense.
June 11th, 2008 | #
Hi, JSF 2.0 specs should try to focus on component JSON objects binding. Developers should work on JSON Proxy and framework injecting values into JSON proxies at run-time.
Component authors can write custom function in JSON binded beans and minimize the server calls.
This all thinking is key to making JSF 2.0 to be next generation specs and applications becoming more rich.
If JSF does not focus on this some other framework will do and surely it will be adopted by community.
All components should be light weight can be controlled client-side and server-side.
Everything has to be annotations based ( class-byte code instrumentation), no more XMLs and base classes please!!.
Charting support is nowhere ?? What kind of enterprise application are we thinking of in 2008.
I hope Java team plans to be very active in JSF 2.0 specs.
June 11th, 2008 | #
I like to see that JSF spec is evolved, but IMO too much efforts are put to implementation specific details (resources, facelets, ajax), whereas most responsibility of specification team should be to establish solid cornerstone API which will allow flexible development on top of it.
For now, most of you will agree with me, that JSF API is far from perfect. The most flawed parts need to be redesigned prior to others are IMO UIComponents hierarchy, state handling, error handling and bootstrap/configuration/hooks.
Its very surprising to me that nobody in JSF spec team seems pay attention to very fruitful ideas described by Jacob Hookom in his blog hookom.blogspot.com 1-2 years ago.
See especially posts JSF 2.0 Ideas (October 26, 2006) and “More JSF 2 Ideas” (May 13, 2007)
In addition to this, my ideas are following: UIComponent API should be as much lightweight and declarative as possible (Interfaces + annotations instead of superclasses and implementations).
This should allow later bytecode instrumentation at runtime.
State management should be revised significantly. In 99% of applications tree structure and most attributes are static and can have application level scope rather than request scope, thus for example, tree navigation can be shared between concurrent requests.
IMO there should be explicit support for stateless pages, I mean, by default pages should be stateless, and there should be special explicit page scope and correspondent API, similar to Session API in servlets, allowing applications and components save/restore only state explicitly need to be associated with the page. Alternatively, declarative approach for state saving proposed by Jacob is very great idea too.
Bootstrap/configuration/hooks part is too very important, for now too much efforts are required to initialize most JSF parts in correct order. I’d add here special initialization hooks, per-component hooks, more generic support of component tree traversal using visitors.
Error handling no doubt should be improved, at least phase listeners should be able to react and catch exceptions thrown during any request phase, with simplified dispatching facilities to bind some error pages to logical outcomes.
Speaking of composite components building, I’m almost satisfied with facelets support, the only problem to solve here is lack of parameterized expression support, but I think this can be solved with declarative component attributes.
Having this solid ground, we will be able to build richer set of functionality later.
June 12th, 2008 | #
It’s too bad more effort is not being put into getting JSF to work properly in a portlet environment. The combination of the two provides a great platform to quickly develop web applications. Unfortunatly, when using the ajax components or anything other than the basic widgits things go south. It would be nice for Woodstock, JSF, and the JSF-Portlet bridge to have better collaberation. If these issues were resolved, this would represent a complete end to end solution.
June 12th, 2008 | #
OK. Let me see if I can get through all the comments.
Rahul said
As I noted above, annotations *are* coming, so we should see things like @Component and @Renderer. What that will look like hasn’t been worked out yet, but they will be in JSF 2. If I remember correclty, we will also be able to leverage the Facelets merge to write renderers as markup rather than Java, similiarly to the technique Ken Paulsen and I demonstrate here: http://java.sun.com/developer/technicalArticles/J2EE/jsf_templating/index.html
Rahul said
We have some of the very sharp JBoss/RichFaces guys (as well as IceFaces, Infragistics, etc) on the Expert Group, so some of the sharpest JSF component minds in the market are weighing in on this. As Ed noted in his talk at JavaOne, the JSF 2 spec won’t be so much innovation (creating new ideas out of whole cloth), but will be more harvesting (that is, taking the good ideas, patterns, etc. that have sprung up and working the best ideas from some of those into the spec). It is my guess that, with regard to the CDK and the article above, things like that won’t be as necessary once JSF 2 ships since it will have native support for easy component development.
Chitra said
I don’t have one.
It sounds like it might be a very valuable tool, but right now, I’m not aware of any discussion about the inclusion of such a feature in the specification.
Chitra said
Mojarra Scales is a small component set that started out as the RI Sandbox. Ryan Lubke opened that Sandbox for experimentation with features, etc., for the RI (now called Mojarra), to which I contributed a number of components. In the last year or so, the sandbox was promoted to its own project, known as Mojarra Scales. You can see the documentation for the library (such as it is) at https://scales.dev.java.net, as well as playing with a live demo at http://jsftemplating.org/mojarra-scales.demo.
Rahul said
Component authors can write custom function in JSON binded beans and minimize the server calls.
This all thinking is key to making JSF 2.0 to be next generation specs and applications becoming more rich.
If JSF does not focus on this some other framework will do and surely it will be adopted by community.
I really don’t expect we’ll see any sort of JSON support in the spec, but that doesn’t preclude adding such support later. I think the flexibility of JSF has been well demonstrated over the years of JSF’s life with the creation of compelling add-ons such as Facelets, Seam, Ajax4Jsf, and the many, many high quality components, both commercial and open source, that are on the market today. Ultimately, when hammering out the specs, the leads (with the help of the EG, typically) have to draw a line somewhere. If we tried putting everything in the spec, we’d never get it finished, and if we did, people would complain that the spec is too big, it does too much, etc. Specifically to your point, if such a feature is, indeed, widely desirable, someone will come up with an extension to provide it. If it achieves widespread use, then it might be considered for inclusion in a future rev of the spec.
Rahul said
Well, the base class ship has already sailed, so I expect UIComponent is here to stay.
Rahul said
There are MANY third party charting options (Scales and jMaki come to mind off the top of my head), so there IS JSF support for this type of thing, just not in the spec.
zdv said
I wouldn’t say that that’s a fair assessment. Jacob’s work and thoughts have had a pretty significant impact, I think, on the direction of JSF 2 (take Facelets, for example). However, as smart as Jacob is, there are lots of other smart people who have differing opinions, so, as a group, we’re taking those opinions and trying to come up with the best amalgamation of them.
zdv said
That is definitely on the agenda: http://tinyurl.com/4kon49
There hasn’t been a great deal of discussion as to what that will look like, but it is certainly going to be addressed, and I imagine Jacob’s thoughts on the matter will be considered very thoughtfully.
By parameterized expression support, do you mean the ability to pass parameters to MethodExpression in the EL? As far as I know, the Unified EL and its syntax, etc., are handled by a separate group, and we’re just consuming their work product. There are EL extensions, such as what JBoss Seam offers, that add that support to the EL, but I don’t expect the EG will address that issue.
OK. I hope I hit the important parts. This has been great feedback. Thanks, everyone. I’ll point the EG at these discussions.
June 12th, 2008 | #
Jason,
There IS work going into making JSF and Portlets easier to use together. We have at least one Portlet 2.0 EG member on our EG, and a fair amount of portlet experience amongst the group. As with a lot of the features, at this failry early stage, it’s hard to say exactly what it will look like, but portlet support (probably 1.x as well as 2.x) is a priority for the spec.
June 12th, 2008 | #
Rahul, I like your thoughts on making the UIComponent model more accessible on the client (i.e. through a JSON proxy or something similar). I think the PDL-based component model currently being defined in JSF 2.0 could accommodate the ability to automatically update (and potentially re-render) components. This is something I plan to think more about and to talk with others to see if its appropriate for the spec. I think there’s a lot of value in having the ability to automatically make the UIComponent properties seamlessly available to client-side JavaScript. And of course we’d need ways of overriding the default behavior when values are manipulated. Very interesting…
June 12th, 2008 | #
Jason>By parameterized expression support, do you mean the ability to pass parameters to MethodExpression in the EL?
No, I actually meant that its currently impossible to pass method bindings to child components in facelets composite components, that is, problem which is adressed here: andrewfacelets.blogspot.com/2006/06/creating-composite-controls-with-jsf.html
June 12th, 2008 | #
zdv,
Ok. That makes sense. That issue is definitely on the radar of the EG. Our goal is import some of the functionality of Facelets (notably, the templating format) and fix some bugs along the way.
June 12th, 2008 | #
Its good to see our comments are being read:smile:
1. If JSF components in future have the capability to bind to JSON proxy (or something similar), this will also mean applications will be able to work in disconnected way. Data will be injected into client proxies and then JSF components can play with the proxy data and minimize server calls.
In order to make sure these do not become stale we need to work on some design thoughts of broadcasting changes etc.
May be Java beans have to in future implement something like IJSONSerializable to make sure it is compatible with JSON requirements and some annotations in this area can be also designed and developed.
1 JSON proxy may be capable of getting binded with multiple JSF client components (DOJO widgets or something similar) and change in JSON proxy should be broadcasted to all binded JSF components.
Here again don’t start thinking of XML, better think of some annotations for JSON also ( I know JavaScript currently does not support annotations, but same can be part of future Java-script, who knows!!. First we need to think in this direction ).
2. Currently AJAX4JSF is best designed ajax library for JSF, I hope JSF 2.0 specs reuse maximum out of this. This part needs to be standardized, currently woodstock 4.3 and AJAX4JSF integration give issues for woodstaock AJAX features. In summary specs should focus on standardizing this by reusing/harvesting existing assets.
June 12th, 2008 | #
Rahul,
They’re always read, and try to reply, but, as you can see, I’m not always real speedy about it.
With regard to JSON support, as I think I noted, there are currently no plans to support that in the spec, but your comments have gotten a couple of people on the EG thinking about it, so you never know.
Regarding a4j, there’s at least one RichFaces dev on the list, as well as ICEFaces, Infragistics, and DynaFaces people, for example, so we have a lot of really sharp Ajax people working on that part. The next release should have the completed Ajax specification (unless community feedback requires that we continue to work on that aspect). Component library interoperability is high on the list of requirements. Hopefully, this won’t be an issue in JSF 2.
June 20th, 2008 | #
Jason Williams: FYI, there’s a separate EG (#301) working on Portlet/JSF integration. Right now we’re targeting JSF 1.2, but since the time line with JSF 2 is overlaps quite a bit, you can guarantee that we’re keeping JSF 2 in mind. There are lot s of JSF 2 EG members in the Portlet Bridge EG.
June 27th, 2008 | #