Ed Burns's Blog

Community: Java Specification Requests Archives

JSF 2.0 Update

Here's an ultra quick update on where the JSR-314 Expert Group is with JSF 2.0 developments. Everything relating to JSF 2.0 Expert Group developments is subject to change until the Proposed Final Draft version of the spec is released.

The ever resourceful and "do-the-right-thing"ful Ryan Lubke has started a series of blog entries showing how to use some JSF 2.0 features. Not all of the below features are showcased in Ryan's blog just yet, but here's a look at what's coming in what's coming (how's that for cutting edge!)

Speaking of cutting edge, if you want to find out how today's top programmers stay that way, check out my new book, Secrets of the Rockstar Programmers from McGraw-Hill, available in stores in March.

• Ajax. Tracked at issue 293.

  We finally have a solution to the thorny, "my component needs a resource (script, stylesheet, image), it needs to be in the HEAD (or body, or form), but I'm not in the HEAD (or body or correct form). Can you please just 'do the right thing' for me?"

  We've decided there will be a top level ajax.js file and that this file will contain the standard JSF 2.0 JavaScript API. We haven't established what will be in this API, but it will have the following attributes:

  • In a page that uses JSF, there must be a top level JavaScript object named "javax", whose type is a JavaScript associative array. We've undertaken the necessary communication with the Open Ajax Alliance, and their Hub concept to reserve the "javax" namespace.

  • Within that top level JavaScript object, found in the OpenAjax Hub, there will be a "faces" property, whose value must be another JavaScript associative array.

  • Within the "faces" JavaScript object, there will be yet another JavaScript associative array, under the key "Ajax".

  • This JavaScript associative array, will have properties that are the JavaScript functions that comprise the JSF 2.0 JavaScript API

  • If any components in the page declare they require the JSF 2.0 JavaScript API, the runtime must guarantee that the ajax.js file is delivered to the client and that this file satisfies the above conditions.

  We're working to finalize spec details on the above items before proceeding with fleshing out the actual JSF 2.0 JavaScript API. I'm certain it will include JavaScript functions for:

  • Partial page refresh via ajax

  • Partial page update via ajax

  • Given a jsf componentId or clientId, give me the client DOM Element that corresponds to the outermost markup for that component.

  • Give me the JSF View State that would be sent in a POSTBACK or Ajax request.

• EZComp. Tracked at issue 273.

  This one has stalled a bit due to Ajax. However, one aspect that has proceeded is MegaListeners. Once we have this checked in, look to Ryan Lubke's Blog <http://blogs.sun.com/rlubke/> for tips on how to use it.

  Two more features of note are the new view scope, and the RAILS_ENV.

The Joy of JCP

I have spent some time this week doing a bit of research about Google's OpenSocial project and, from my perspective, it doesn't seem so open. None of the heavy hitters in the server side application platform market are participating. This can concievably be explained by the fact that OpenSocial is all about REST and JavaScript. "The Web is the Platform" not, "The App Server is the Platform", so naturally the server side application usual suspects would not be included. Why then is Oracle listed as a partner? In the world of server side applications, Oracle's chosen platforms have been Java and (somewhat) .NET. If OpenSocial was truly open, wouldn't you expect Oracle's peers, the other major players in the server side application space, to be invited?

Leaving Oracle aside, there were some other glaring omissions from the web 2.0 space. Neither Yahoo! nor Facebook participated. Were they invited? Won't people want to use Flickr based apps on their chosen social platform? Finally, if you want to call something open, there's usually some sort of governancy body that ensures the stakeholders are equally represented (for some definition of "equal").

The Job of the JCP Spec Lead

I'd like to contrast this with the (admittedly much smaller) world of the Java Community Process (JCP) and my (smaller still) view of it as the co-spec lead of the JavaServer Faces (JSF) 2.0 Expert Group (EG).

At the beginning of October I received an email from JSF stake holder and JBoss representative Gavin King. Gavin had some concerns about how I had been running the JSR. Chief among them was his concern that the important voices in the JSF community were not being herd on the EG. While I respectfully disagreed about that being the case, I agreed to make some changes to address his concerns.

One such change was to delegate the initial design work for our top priority issue for JSF 2.0 to JSF stake holder and Facelets creator Jacob Hookom. Jacob shared his initial sketch with the EG today and immediately we had useful constructive feedback from Ken Paulsen, creator of JSFTemplating, and Gary VanMatre, creator of Apache Shale Clay. That means all of the major templating languages for JSF are actively contributing to JSF 2.0. That's JCP at its best.

JSF 2.0 EG Kick Off Meeting: Buy a Feature

Even though we haven't yet officially filed the JSR for JSF 2.0, we're darn close, and I felt we could not afford to miss the opportunity to have a JSF 2.0 Expert Group kick off meeting at JavaOne this year. Once again we were blessed with a great turnout (19 people, including a special visit from Jonathan Schwartz, see the roster). Instead of spending time gathering requriements or kibbutzing, I decided the requirements we have already gathered were good enough for now. Our first order of business as the JSF 2.0 Expert Group was to prioritize these requirements so we can build a schedule.

To complete this exercise, we used one of Luke Hohmann's Innovation Games: Buy a Feature. From Luke's description:

Create a list of features with an estimated cost. The cost can be development effort or something else; although the cost can be the actual cost you intend to charge for the feature, this is usually not required. Customers buy features that they want in the next release. Make certain that some features are priced high enough that no one customer can buy them. This will help motivate negotiations between customers as to which features are most important. Encourage customers to pool their money to buy especially important / expensive features. Works best with 4-5 customers in a group, so that you can create more opportunities for customers to pool their money through negotiating.

"Buy a Feature" is just one of the great games in Luke's book, Innovation Games: Creating Breakthrough Products Through Collaborative Play .

Exercising spec lead authority, I looked at 1) the JSR draft, 2) the Requirements Scratchpad, and 3) Alex Smirnov's requirements document, and picked 15 requirements using a weighting algorithm. I assigned prices to each based on how much spec effort I thought it would take to specify each feature. I took the final 15 into the meeting. JCP Experts being JCP Experts, there was some disagreement over my inclusions and omissions from the list. I pushed aside this disagreement, for the most part, and only allowed two changes to the menu at the meeting. The actual menu used at the meeting follows.

Playing the Game

We broke down into groups of four, and Roger Kitain, Dennis Byrne and I played the role of feature retailers. Dennis Byrne, who works for world-famous XP Consulting firm ThoughtWorks remarked that his firm uses similar techniques to discover the preferences of clients. From his experience in playing such games, he was very pleased with the amount of high quality discussion in the groups, and so was I. These people clearly had strong opinions about web application frameworks, but at the same time were professional in sharing them. The collaboration aspect of the game was a success, which in itself is a good outcome to a JCP Expert Group kick-off meeting.

After each of the four groups had completed their shopping, I collected the results which are summarized in the following table.

Conclusion

There were some problems with the exercise. Ever the inveterate gamer, Howard Lewis-Ship pointed out (sadly, after the exercise was complete) that we had given too much money to each individual, which under-constrained the participants and thus masked their true feelings. This was an honest miscalculation, which I deeply regret. In addition, participants complained of a lack of consistent level of detail among the menu items. Some were very low level and specific, others high level and generic. This required each group to re-define the generic items for their own purposes, and naturally each one did it in their own way. Each menu item was not cleanly disjoint from all the others, leading to a participant to have to choose between items that both possesed some of what they were looking for. In spite of these problems, I consider the exercise a success, for the experience in playing it for future meetings, and, to a lesser extent, for the hard data produced.

Postscript

Finally, I was delighted to have bumped into Jonathan Schwartz in the halls of the Sun building where the meeting was being held. Having known Jonathan from my days at Lighthouse Design, and knowing that deeply understands developers, I felt confident in asking him to stop by the meeting and thank the EG members for donating their time to the Java Community Process. He went one step further and hung out for a little bit collecting data on how well the EG members felt the JCP was working.

Attendees

Pre-JCP-filed draft for JavaServer Faces 2.0 JSR

It's about time we get moving on JSF 2.0, so Sun's JSF team decided to go public with a pre-JCP-filing of the JSR for JavaServer Faces 2.0. The draft of the document at <https://javaserverfaces-spec-public.dev.java.net/proposals/JSF-2_0-draft.html> has been through several rounds of Sun internal review and also was reviewed by the JSF 1.2 Expert Group. Please review the draft and post comments here on this blog.

If you want to go even deeper into shaping JSF 2.0 and the JSR submission, you can view and edit the wiki for a JSF 2.0 Requirements Scratchpad document. When the JSR gets rolling, the requirements in that document will be turned into issues in the JavaServer Faces Specification Issue Tracker.

Finally, I'd like to take this opportunity to extend an invitation to several individuals outside of the JSF community to join us in developing the next version of the Java standard web application framework. Specifically, I call upon Howard Lewis-Ship, Geert Bevin, Eelco Hillenius, and Tim Fennell to consider Joining the JCP so they can join the Expert Group when it forms. Of course, there are many other folks whose expertise would be appreciated on the Expert Group, but Howard, Geert, Eelco and Tim come to mind because each of them has their own web framework outside of JSF.

Please let us know what you think about starting JSF 2.0!

This work is licensed under a Creative Commons License.