ICEfaces 2 is the new version of the ICEfaces framework that integrates with JavaServer Faces (JSF) 2. With ICEfaces 2, our goal is to deliver the highest value existing ICEfaces features, as well as important new enhancements, cleanly integrated into the JSF 2 platform. There are a number of ways to take advantage of ICEfaces 2 in your JSF 2 application:
First, add the icefaces.jar to your project. This immediately allows you to take advantage of Direct-to-DOM (D2D) rendering technology. D2D only sends browser DOM changes from the server to the browser, minimizing bandwidth consumption without the need to specify the new "f:ajax" component in your pages. Once the icefaces.jar is added to your project, you can also take advantage of ICEfaces Window Scope and Single Submit features.
After adding the icefaces.jar to your project, you can start adding components:
- The "ICEfaces Advanced Components" are next-generation ICEfaces components. They are based on the all-new Advanced Component Environment (ACE) component development platform which implements a consistent approach to component authoring, meta-data management, and automates common component development tasks and optimizations.
- ICEfaces 2 provides a compatible component library based on the ICEfaces 1.x component suite. This set of components are referred to as "ICEfaces Components" and immediately allow developers to build ICEfaces 2 applications with a mature AJAX component suite.
Finally, you may want to take advantage of asynchronous server-initiated updates using ICEpush. ICEpush draws on years of expertise with Ajax Push in ICEfaces/JSF and gives applications the power of real-time, web-based collaboration.
This tutorial makes use of a JSF 2 application. The application consists of a page to add a new Job Applicant:
And a page that displays the applicants:
The clear button in job-applicant.xhtml consists of the following markup:
Here we see the use of stock JSF tags including the new f:ajax tag. The render="@form" attribute on the f:ajax tag informs JSF that only the form should be rendered after the lifecycle is executed.
Pressing the "Clear" button under these circumstances will generate the following response, which includes the entire form:
ICEfaces 2 renders component markup to a server-side DOM (Document Object Model) that reflects the current client view. Each time the JSF lifecycle runs a DOM comparison is done and, if there are any changes, a concise set of page updates are sent back to the client to be applied to the page. We call this Direct-to-DOM or D2D rendering.
Adding the ICEfaces 2 library to an existing JSF 2 application will provide dynamic partial-page-updates for all compliant components, without the need to specify the "f:ajax" component in your pages.
Simply add the icefaces.jar to the application and we have Direct-to-Dom (D2D) rendering applied to the page. Now, when we press the "Clear" button, we get the following response which only updates two hidden fields:
Notice the difference in the amount of markup sent back in the response – and this is for a small form with only four fields. Direct-to-DOM rendering is powerful stuff. The beauty is that from a developer point of view, it takes place automatically under the covers. This is what we call 'Application Level AJAX'. The AJAX is built in to the framework and you do not have to concern yourself with how updates are applied, Direct-to-DOM rendering takes care of it for you.
- A list of String data
- A list of arbitrarily complex child components
The following code sample shows an implementation using a list of String data:
This will display a drop-down list of cities that match the text input. The 'rows' attribute defines how many results will be returned when text is entered. The 'width' attribute sets the width of the input text box and the drop-down list. The 'valueChangeListener' attribute binds to a backing bean method that determines the associated list when a value is changed.
Nested in the ice:selectInputText component tag is an f:selectItems JSF tag. The 'value' binding in this tag provides the list of available options. The screen shot below shows the component in action:
Unable to render embedded object: File (autocomplete-action.png) not found.
The following code sample shows an implementation with a list of arbitrarily complex child components:
This will display values similar to the first way but adds more information to the drop down menu, such as state and zip, in addition to the city. The screen shot below shows this method in action:
Unable to render embedded object: File (autocomplete-action2.png) not found.
In the application we use three main backing beans:
- AutoCompleteBean: Stores the values gathered from the AutoCompleteDictionary class. Also contains utility methods for updating the list and getting the matches from the dictionary list.
- AutoCompleteDictionary: Gets the dictionary list from a file in the file system. Also sorts the dictionary appropriately.
- City: Basic class used as an object in the dictionary list.
The backing beans retrieve lists of viable options from AutoCompleteDictionary. Our dictionary is populated from an xml file as follows:
In this case, we have encapsulated the options available to the user in a zipped xml file that is deployed with the applications. Options available to the user could also be retrieved from a database.
|autocomplete-tutorial||[autocomplete-tutorial source code|^autocomplete-tutorial.zip|Download Source Code]||Simple example on how to use the Auto-Complete component.|