Ed Burns is a senior staff engineer at Sun Microsystems. Ed has worked on a wide variety of client and server side web technologies since 1994, including NCSA Mosaic, Mozilla, the Sun Java Plugin, Jakarta Tomcat and, most recently JavaServer Faces. Ed is currently the co-spec lead for JavaServer Faces.
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.
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.