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.

Table 1 - Menu of JSF 2.0 Features available for purchase
Feature Name Feature Cost (USD)
Facelets Real world, production view description technology, including templating: include something influenced by Facelets, JSFTemplating or Tiles in the specification. Also includes component aggregation: allow development of true JSF custom component with little or no Java coding by aggregating existing simple components. 165
Zero Deployment Time Eliminate the "deployment step". All the artifacts that comprise a JSF application can be modified while the application is running. This will bring the responsiveness people have been used to with iterative JSP development to the JSF developer. One design idea for this is to allow JSF artifacts to be authored in Script. 100
EZComp Make it really easy to create JSF custom components. 100
Ajax Expand the request processing lifecycle to be aware of Ajax. This may include describing a small developer-contract footprint JavaScript library as part of the JavaServer Faces specification. Enable components to have a client based lifecycle in addition to, or instead of the server based request/response lifecycle. Such a client based lifecycle would enable use-cases such as drag-and-drop, master-detail and sub-dialogs on a single page interface web application. 80
Errors Better Error reporting, like what you get with Tapestry (also in JSR-252-EG, where it was said: any time there is an error in *any* part of the lifecycle, the user should see not just a cryptic stack trace, but also the component - including file and line number - that triggered the problem, the EL expression that was being evaluated - including the part of the EL expression that triggered the problem, etc. Diagnosability for state saving is also important. On this point, Gavin King wants to have centralized error handling, with an interception point, perhaps using navigation rules, to help handle errors.) 80
MegaListeners You want to be able to add listeners for various kinds of lifecycle application events. Maybe, "call this each time something validates," or "call this after everything successfully validates." "before JSF initializes", "after JSF is done initializing", 50
Convention over Configuration Allow for "zero configuration" web applications. No faces-config.xml, no web.xml. 50
Mostly GET Allow for bookmarkable JSF pages. More broadly, if HTTP GET can be used, it should be used. 80
AnnotationFest Leverage annotations to declare JSF artifacts (components, managed beans, navigation rules, etc) to the runtime. 25
Declarative Rendering Declarative Renderers, otherwise known as Renderers without resorting to out.println(). 25
Fix State Saving Re-do UIComponent state saving with a view towards making stateless components the default. 80
Skins "Skinning", or "Themeing" of components. This also would include per-user personalizations that could be applied to the components. 60
Singleton Precedence ViewHandler (and other parts of JSF) ordering when there are multiple implementations -- also perhaps restrict to certain URLs 40
Validation++ Decent inter-component and form-level validation 15
Programmatic Config Access Programmatic access to and modification of faces-config.xml and web.xml, perhaps as a DOM instance. 50
Total 1000
Table 2 - Purchased Features
Feature Name Number of units purchased
Ajax 5
Facelets 4
Annotations 4
State Saving 4
Validation 4
EZComp 3
Errors 3
Mostly GET 3
Singleton Precedence 3
MegaListeners 2
Declarative Renderers 1
Convention over Configuration 1
Skins 1

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

Table 3 - Attendance Roster
Group Name Representing
1 Gavin King RedHat (from JBoss)
Kito Mann Self
Stephen Kenna IBM
John ? Computer Associates
2 Jacob Hookom Self
Howard Lewis-Ship Self
Martin Marinscheck Apache Software Foundation
Alexander Smirnov Exadel
3 Manfred Geiler Apache Software Foundation
Keith Donald Interface 21
Peter Yueng Ericsson
Damien Garbarino ILOG
4 Cleo Baretto ILOG
Howard Abrams Computer Associates
Igor Shabylov Exadel
Ted Goddard ICESoft
Facilitators Ed Burns Sun
Roger Kitain Sun
Dennis Byrne Apache Software Foundation
Comments
Comments are listed in date ascending order (oldest first) |

  • Hi Ed. I liked reading your report. The results of the game astonished me at first as I would have spent my money way differently. I guess that the most distorting influence to a representative outcome (rather than an inappropriately chosen amount of allotted money) might have been the circumstance that the buyers were in most part simulated not by actual JSF customers but rather by JSF (-tool) vendors. I would like to suggest a minor but useful feature: Within a given JSF view, it is most commonly the case that many attributes of components are set to the same values. For example, consider the style- or class- attribute on components of the same type in a portlet application. A view that has 20 labels, each to have it's class attribute set to portlet-section-text or whatever valid portlet style, each configured to have a tool tip with content fetched in the same way etc. A view is cluttered immensely by this reoccurring specification of common default settings on components. People focus much on how facelets reduce the complexity but I think a mechanism for setting attribute defaults for component types might have an even bigger effect. Consider the following sketch. Before:
    <f:view>
    	<x:comp1 header-style="portlet-section-header" inset-style="portlet-section-text" tooltip="#{lookup(me.id)}" value="first" />
    
    	<x:comp1 header-style="portlet-section-header" inset-style="portlet-section-text" tooltip="#{lookup(me.id)}"  value="second"  />
    
    	<x:manyMoreComponents />
    </f:view>
    
    After:
    <x:default attribute="comp1.header-style" value="portlet-section-header" />
    <x:default attribute="comp1.inset-style" value="portlet-section-text" />
    <x:default attribute="comp1.tooltip" value="#{lookup(me.id)}" />
    
    <f:view>
    	<x:comp1 value="first" />
    	<x:comp1 value="second"  />
    	<x:manyMoreComponents />
    </f:view>
    
    Or course, these examples need to be looked at with goodwill. The view content and attribute use is not profuse enough to illustrate the profit of specifying attribute defaults. Also, most components that vendors offer have a host of attributes and being able to set attribute defaults on application-level and page-level is a kind of customization that is easy to add and should make JSF appear even more powerful because one could showcase how impressive rendering results can be achieved with even less code. Last but not least, such a kind of attribute defaulting might also alleviate the need for a dedicated skinning functionality. -- P.S.: a clever customer would only buy declarative renderers and furthering the useability of JSF for templating outside the context of web-applications as this will buy him heaven thereby making them rich enough to buy all other features of all forthcoming releases :D

    Posted by: wtff on May 15, 2007 at 08:09 AM

  • BTW, one could also think of this proposal as "server-side style sheets".
    Directives outside of the actual page components that customize the components by setting default for them.
    <x:defaults>
         comp1 {
               header-style: portlet-section-header;
               inset-style: portlet-section-text;
               tooltip: #lookup(me.id)
          }
    </x:defaults>
    
    What's right for the client can't be wrong for the server, right? The stylesheet metaphor might inspire further ideas around attribute defaulting, like inheritance among styles or contextualization of style directives as in h1.div { ... } etc

    Posted by: wtff on May 15, 2007 at 08:33 AM

  • I am a JSF customer, and I find the voting to be right in line with my preferences. I agree with the conclusion that of the "expensive" features, zero deploy time--while nice to have--doesn't have the same bang-for-buck as the others. (I assume it not making Table 2 suggests this.) Would be great for those who really want it to be able to seek it out as an extension (JSF-Ext or otherwise), but I'd rather the spec focus on the other biggies.

    On the "Ajax" item- I love the idea of a client-based lifecycle, but I have a problem with allying this feature so closely with Ajax. With Flex and potentially applets (with JavaFX) gaining traction, the spec should, at the very least, have a pluggable client-side architecture that allows different components/component sets to be comprised of non-Javascript entities. For example, the spec should make it possible for an enterprising 3rd party to wrap the entire set of Flex 2 components (now open-source) into JSF counterparts, communicating back and forth using this pluggable client-side architecture. This could be done today, by using a combintion of DynaFaces, Adobe's FABridge JS-Flex bridge, and a little glue code; but it would be great if JSF 2.0 provided extension points making it easier.

    Or, if you prefer, this being a Sun blog :), imagine that once the mean 'n' lean consumer JRE comes out mid '08, a Java.net project that marries JavaFX with JSF comes out, wrapping various rich client-side controls in JSF components that let you keep logic (and bizObjects) back on the server.

    I don't know ... the further these rich technologies come (Flex 2's MXML is a fantastic example of EZ component composition/extension/definition, b.t.w.), the more I wonder how much sense it makes to kill yourself building Ajaxified components like Trees and whatever else in DHTML/Javascript- or, at the very least, to define the JSF spec narrowly enough such that alternatives aren't facilitated.

    Posted by: rogers_reilly on May 15, 2007 at 09:09 AM

  • >> On the "Ajax" item- I love the idea of a client-based lifecycle, but I have a problem with allying this feature so closely with Ajax. I fully agree. The JSF spec should be evolved with Ajax in head but shouldn't Ajax written anywhere on it.

    Posted by: wtff on May 15, 2007 at 10:09 AM

  • Components, Components, Components!

    Creating components that works in any JSF container is as fun as coding bytecode directly. It is very hard to get ROI on a component unless you are a big company that can create its own component creation framework.

    Posted by: mikaelgrev on May 15, 2007 at 10:18 AM

  • As one of the "facilitators" of this process I can say that I thought it was a refreshing change to the normal "sit back and white board it" approach. The process kept all EG members involved. Nice work Ed! -roger (JSF co-spec lead).

    Posted by: rogerk on May 15, 2007 at 11:54 AM

  • Better error reporting! In my experience, the Stack Trace from Hell does more to turn off people from JSF than anything else. It is such a relentless productivity killer. I am surprised that it didn't rise to the top instantly. You all have become too good at reading stack traces :-)

    Posted by: cayhorstmann on May 15, 2007 at 09:41 PM

  • cay, without a doubt, error *handling* is at the top of people's priorities, but when it came time to bet on what most of us assumed was an implementation detail not an API focus-- we'd vest our dollars elsewhere ;-)

    Posted by: jhook on May 15, 2007 at 09:56 PM

  • I'd have bought (in order of priority):
    • Facelets (esp master/client templating)
    • Ajax
    • EZComp (Declarative Rendering might have been included here)
    • Mostly GET
    • Fix state saving
    That's $505. Did I overspend? The only additional items from my list of ideas I'd press for would be:
    • Conversation scope
    • Page Lifecycle ala Shale ViewController
    • Standard method to package and fetch component resource (e.g. images)

    Posted by: rogerkeays on May 16, 2007 at 12:54 AM