Wednesday, 1 July 2009
On the road to ICEfaces 2.0
« Ajax Push for Data Visualization | Main | Ajax vs JavaFX »Although ICEfaces 1.8 currently runs on JSF 2.0, it doesn't make use of many of the new features (but it is a good demonstration of the backwards-compatibility of JSF). To really take advantage of JSF 2.0, it is necessary for ICEfaces to leave its JSF 1.1/1.2 legacy behind. You can find the beginnings of this here under the codename "glimmer":
http://anonsvn.icefaces.org/repo/icefaces/scratchpads/glimmer
One of the biggest changes is brought by the standardization of Ajax input and output in JSF 2.0. When a user event is received in the browser, the containing form is serialized and sent to the server. On the server, the JSF lifecycle runs, decoding the serialized form and executing the application, resulting in an edit list of changes for the browser page. The edit list is returned, and the page is updated in-place. ICEfaces 2.0 makes use of this fundamental Ajax capability, but adds in Direct-to-DOM rendering to make application development easy. In effect, D2D rendering automatically determines the page update regions, eliminating the need for defining the regions manually, such as with:
<f:ajax execute="reset" render="form1"/>
The extension points provided by JSF 2.0 for this are found mainly in the PartialViewContext and ResponseWriter classes. For ICEfaces, this allowed considerable simplification because it allowed the unique aspects of ICEfaces Ajax capabilities to be implemented on top of the more common aspects of other frameworks, now built into the standard implementation.
Of course, another compelling feature of ICEfaces is Ajax Push, and we have implemented this differently for JSF 2.0 as well. The new strategy can be described as "notification/refresh". In ICEfaces 1.8, page updates for Ajax Push are determined by creating a synthetic request on the server, allowing the JSF lifecycle to run for that request, then pushing the page changes to the browser. This strategy has the advantage that page updates can be delivered with a minimum of HTTP traffic, but it has the disadvantage of a synthetic request (resulting in implementation complexity for ICEfaces). The notification/refresh strategy works as follows: when a render is requested, a notification is pushed to the browser, whereupon it makes an Ajax refresh request to the server, causing the JSF lifecycle to run, and current page updates to be returned and applied. (Note that we may bring back the synthetic request push capability as an optimization for mobile devices.)
Keep in mind that ICEfaces 2.0 will undergo significant changes from now until release, including major API and implementation changes, but if you're curious to play around with Ajax Push on JSF 2.0 and are interested in participating in the ICEfaces open source community, please fire up your subversion client, check it out, and invoke "ant".
You'll be able to learn more about this in person at CommunityOne
and JavaOne:
Posted by at 6:25 PM in Entries by Ted Goddard