ICESoft has released of a free community edition of their AJAX enabled JSF development and deployment solution, ICEfaces Community Edition v1.0 Beta. Using a Direct-to-DOM rendering technique, ICEfaces generates and presents a server-side representation of the applications presentation layer over a lightweight AJAX bridge. The bridge also provides fine-grained eventing and partial submit mechanisms to communicate user interaction back into the server-side application where they can be handled naturally within the JSF application lifecycle.

ICEfaces Community Edition support for rapid development and deployment of rich thin-client web applications comes with the following key features:

• Incremental UI updates without full-page refresh (via developer-transparent AJAX/AHAH bridge).
• Server-initiated asynchronous UI updates without polling (supports server-push or "COMET" applications)
• Complete rich JSF component suite, including Auto-complete, Menus, Table, Tree, Tabs, Drag & Drop, animation effects, etc.
• Direct API support for group-aware application development (chat, webcast, social apps., etc.)

ICEfaces directly leverages existing J2EE-standard JSF technologies and tools to provide a complete RIA development and deployment solution.

Key differentiators are:

• Complete server and client-side AJAX application framework solution - no need to hand-assemble and integrate client-libraries and server technologies
• Develop applications using Java, not JavaScript - no need to deal with browser-specific idiosyncrasies in DOM
  and JavaScript support
• Leverages widespread industry support for JSF development tools and runtime environments - no need for proprietary tools and technologies.
• Leverages existing technology investments (tools, application servers, etc.) and developer skills.

With the v1.0 Beta release we are actively seeking out developer feedback on all aspects of the product. Please feel free to submit comments, questions, and suggestions on
the ICEfaces community forums.

More information:

• Demos
• Free Download
• Release Announcement
• More Info

server side ajax is indeed the way to go, javascript can be minimized to the max this way ;-) Calling java code from the client side is NOT the way to go, it is the road to nowhere.

How does this compare to stuff like Potix's ZK ? What are the pros and cons in the context of other similar frameworks ? Any elaborations would be helpful...

ZK has a number of good ideas. Like ICEfaces, a complete initial page is fetched and user events are processed by the server to generate updates to be applied to the browser DOM. Also like ICEfaces, the developer need not write any JavaScript to produce AJAX applications.

Unlike ICEfaces, the ZK development environment is specific to ZK (ICEfaces is standard JSF). Also, ICEfaces supports application-initiated rendering, allowing events on the server to trigger updates to the browser page. ZK appears to be entirely user-event driven (perhaps someone more familiar with ZK can comment).

ZK allows the UI in the browser to be updated from any thread in the server, not just from the events. So in this sense, ZK is not entirely user-event driven.

Does ICEfaces provide something simmilar to Oracle ADF faces process scope or JBoss Seam conversation context?

This is essentail for building boolet proof rich client web applications in the same way as having stateful components like JSF ones.

It's configurable, but the ICEfaces request scope defaults to what is essentially "process" scope -- request scope boundaries are taken to be full page requests. That is, user events sent over AJAX from the same window are not typically in different request scopes.

Ideally, a new standard "process" or "conversation" scope for JSF should be defined:

http://weblogs.java.net/blog/edburns/archive/2006/03/repost_bringing.html

This is great library indeed.
One thing I miss in almost all JSF component libraries is that some GUI events like tab selection in tab control or tree expand/collapse could and should be all client side (at least configurable). Sometimes user experince is better if these events are completely client side, sometimes not.

All date picker events also should be client side.

This is great library indeed. One thing I miss in almost all JSF component libraries is that some GUI events like tab selection in tab control or tree expand/collapse could and should be all client side (at least configurable). Sometimes user experince is better if these events are completely client side, sometimes not.

Ahem, Tobagao has a client side tabbing, Tomahawk also, and probably ADF as well ;-)

Ahem, Tobagao has a client side tabbing, Tomahawk also, and probably ADF as well ;-)

ADF don't.

This is great library indeed. One thing I miss in almost all JSF component libraries is that some GUI events like tab selection in tab control or tree expand/collapse could and should be all client side (at least configurable). Sometimes user experince is better if these events are completely client side, sometimes not.

Mileta,

I am glad to hear your praise of ICEfaces. I hope you will give ICEfaces serious consideration for your next project.

I agree with you that there are cases where client-side support is natural (eg: date picker), or required (eg: drag and drop), but one of the underlying philosphies of ICEfaces is that user interaction with the presentation is likely to be of interest to the application and should be communicated. So we seek a balance between responsiveness of client-side operations and the importance of the server-side application being in sync with the users actions.

Drag and drop is an excellent example of this balance, where you require client-side support to achieve the interactive part, but you want the user interactions communicated back into the JSF application where business logic can interpret and handle the interactions between dragable and dropable elements.

The greatest benefits are achieve when client-side support can provide immediate responsiveness to the user, and the JSF application is given the opportunity to effect additional presentation changes as appropriate. As the ICEfaces component suite matures, we will continue to add client-side support as appropriate, but will always ensure that the interaction model is tied back into the JSF lifecycle, where the application can respond intelligently to the user.

Steve