Greg Murray's Blog

BluePrints for writing JSF Components that use AJAX

Tor Norbye from the Creator team, Ed Burns who is one of the JSF specification leads, and I have created a new BluePrints Solution Catalog entry titled: Using JavaServer Faces Technology with AJAX.

This document details questions a JSF component developer may face when developing AJAX enabled components.

• Should AJAX request handling be done in a separate servlet controller or should it be handled by the JavaServer Faces technology life cycle?
• How can existing components be AJAX-enabled without rewriting them?
• Should JavaScript code be embedded in Java code or externalized in a separate script file?
• How does the programming model differ between component writer and page developer?
• How should I organize the project structure in my workspace?
• How should I package the JavaServer Faces objects and JavaScript artifacts into a WAR file or EAR file?

We discuss 3 strategies for developing JSF components that support AJAX which include:

• A Custom JavaServer Faces Component Renders Client-side AJAX JavaScript and Processes AJAX Requests -
  All AJAX related atrtifacts are rendered by the JSF component. The JavaScript code is also rendered by the JSF component. This is recommended Strategy for developers creating new JSF components where the page developer needs to simply reference the component in the page and everything else is taken care of.
• Strategy 2: A Custom JavaServer Faces Component with Separate AJAX Controller - A means of separating JSF code from AJAX processing code. In this case the developer is given a little more flexibility at the expense of not being as closely coupled to the JSF runtime. This solution is great for those that want to centralize AJAX processing or potentially use the same AJAX processing code outside of the context of a JSF runtime.
• Strategy 3: Retrofitting an Existing JavaServer Faces Application -
  This solution focuses on how an exsiting JSF component or application may be AJAXified.

There are two separate entries which implement Strategy 1. These solutions are Autocomplete JSF Component and Progress-Bar JSF Component. Both examples have working component code and sample applications that showcase the components.

For more details on these strategies see: Using JavaServer Faces Technology with AJAX.

Please tell us what you think.

Comments

• Greg,

  Thanks to you, Tor, and Ed for putting this all together.

  As with many others, I was intrigued and excited when I saw Ben and Dion's AJaX demonstration at this year's TSSJS in Las Vegas, but I was disturbed by its disruptive nature (with respect to how it would fit into existing coding practices and frameworks).
  
  I think you've clearly shown that JSF is a great way to "tame" AJaX: We can have the power of sub-page refresh without losing the elegance of a component oriented framework.

  What do you envision in terms of tool support to help generate AJaXian JSF components, and what additonal support would you add to something like Java Studio Creator for working with such components?

  Thanks again,

  John

  Posted by: johnreynolds on June 21, 2005 at 06:10 AM

• I had posted a couple issues to the specification for JSF 2.0 on the topic. The first being that there is a strong need for standardizing client side scripting support within the Renderers. Right now, every component seems to do their own thing. The second issue is supporting submission of branches or single components back to the FacesServlet to support 'refreshing' parts of the document with AJAX.

  Really, there are two 'kinds' of AJAX support. One is delivering XML data, and the second is framework specific AJAX to support dynamic JSF. I don't think anything will be accomplished by trying to come up with a generic solution for delivering XML data to Javascript in the page. We really don't know where AJAX is headed at this point and we could be looking at RSS feeds, RPC, WS, etc. I say leave that alone under Strategy 2, independent of JSF.

  Now things like auto complete and refreshing components on the screen, I can see standardizing a kind of AJAX event system that components can use, like JAXB/RPC, without worrying about the XML generation or interpretation. I think this would be the only focus of a JSF 'strategy'. Again, leaving generic XML 'data' transfer out of the scope of JSF.

  Jacob

  Posted by: jhook on June 21, 2005 at 07:22 AM

• Tor and I will be talking more about AJAX enabled JSF components and Java Studio Creator at JavaOne. If you get a chance look for session "Rich Web Applications With the J2EE™ Platform and AJAX" on Tuesday June 28th in the Esplanade 307-301 at 11:00 AM. For those that can not be there for JavaOne we will try to blog more about this after JavaOne.

  Posted by: gmurray71 on June 25, 2005 at 07:08 PM

• Having a framework that would map a back end representation of a JSF component model via XML and have it updated dynamically by altering the HTML DOM is a topic that has come up a time or two. This would require a client-side framework as well. This is something we are thinking about. Keeping the models on both sides in sync would be challenging.

  Posted by: gmurray71 on June 25, 2005 at 07:33 PM

• Hi Greg,
  Am new to the Ajax technology. but i have gone thru some ajax books but i still have problems with working effectively. The problem i was given to do was to update an svg file from the server. Pls i don't know if you can offer me assistance. my boss is on my neck for an output and am getting really stressed up.

  NB:
  Pls i would love to have your email addres so i can send my codes to you for corrections.
  Thanks once again

  Hilda

  Posted by: hilda on December 01, 2006 at 08:22 AM

This work is licensed under a Creative Commons License.