1. SCOPE
This page is intends to briefly explain overview of ICEfaces with Its AJAX capability components. It summarizes problems occurs while using ICEfaces with JSF portlets. What are benefits of using D2D. Suspicion areas while using D2D.
2. ICEfaces overview
1. ICEfaces is extension to JSF for providing rich UI experience by enhancing JSF framework and lifecycle with AJAX based feature.
2. ICEfaces provides an extensive Ajax-enabled component suite that facilitates rapid development of rich interactive web based applications.
3. Portlet development using ICEfaces 2
Portlet support in ICEfaces is now provided by the PortletFaces Bridge, an implementation of the JSR 329: Portlet 2.0 Bridge for JavaServer Faces. The portlet bridge specification technically applies to JSF 1.2 but the PortletFaces version been adapted to support JSF 2. The PortletFaces Bridge is tested and shipped with the ICEfaces 2 distribution and can be used to develop portlet applications with ICEfaces.
portlet.xml
ICEfaces 2 makes use of the PortletFaces Bridge to handle the mapping of the portlet lifecycle onto the JSF lifecycle. This has many advantages like enabling proper resource handling and cleaner integration with the portal container.
<portlet>
<portlet-name>chat-ice2-portlet</portlet-name>
<display-name>Chat</display-name>
<portlet-class>org.portletfaces.bridge.GenericFacesPortlet</portlet-class>
<init-param>
<name>javax.portlet.faces.defaultViewId.view</name>
<value>/view.xhtml</value>
</init-param>
</portlet>
The important parts are:
· The portlet-class, which needs to be defined as org.portletfaces.bridge.GenericFacesPortlet.
· The javax.portlet.faces.defaultViewId.view which should identify the page that is the initial view of the portlet.
3. Portlet development using ICEfaces 1.8
portlet.xml
... <portlet>
<portlet-name>toggleMessage</portlet-name>
<portlet-class> com.icesoft.faces.webapp.http.portlet.MainPortlet </portlet-class>
<init-param>
<name>com.icesoft.faces.portlet.viewPageURL</name>
<value>/toggle.iface</value>
</init-param>
</portlet> ...
The <portlet class> is the fully qualified class name of the class that implements the Portlet interface. ICEfaces has its own portlet, which could be considered a bridge of sorts, that handles incoming calls from the portal container and passes them on to the ICEfaces framework. You must use this portlet or a subclass of this portlet as the <portlet-class> value. The <init-param> setting uses a key of com.icesoft.faces.portlet.viewPageURL. The value of this parameter is the initial view that the portlet displays on the initial render pass. It is important to use the .iface extension to ensure that the request is properly handled by the ICEfaces framework.
DD Configuration
As an extension to JSF, ICEfaces provides its own version of the FacesServlet (PersistentFacesServlet)
as well as an additional Servlet (BlockingServlet) for handling asynchronous updates. We register these
Servlets in the deployment descriptor file (web.xml) by adding the following entries:
<servlet>
<servlet-name>Persistent Faces Servlet</servlet-name>
<servlet-class>
com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet
</servlet-class>
<load-on-startup> 1 </load-on-startup>
</servlet>
<servlet>
<servlet-name>Blocking Servlet</servlet-name>
<servlet-class>com.icesoft.faces.webapp.xmlhttp.BlockingServlet</servlet-class>
<load-on-startup> 1 </load-on-startup>
</servlet>
We also need to add a new Servlet mapping of PersistentFacesServlet to .iface.
<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>*.iface</url-pattern>
</servlet-mapping>
We also need to add a couple of mappings for ICEfaces’ internal use.
<servlet-mapping>
<servlet-name>Persistent Faces Servlet</servlet-name>
<url-pattern>/xmlhttp/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>Blocking Servlet</servlet-name>
<url-pattern>/block/*</url-pattern>
</servlet-mapping>
5. D2D
Direct-to-DOM (D2D) rendering is just what it sounds like—the ability to render a JSF component tree directly into a W3C standard DOM data structure. ICEfaces provides a Direct-to-DOM RenderKit for the standard HTML basic components available in JSF.
The way this basic Direct-to-DOM mechanism is deployed in an ICEfaces application involves server-side caching of the DOM and an Ajax bridge that transmits DOM changes across the network to the client browser where the changes are reassembled in the browser DOM.
When the ICEfaces JAR is included in your JSF application, the Direct-to-DOM RenderKit is automatically configured into the application. There are no other considerations from the developer perspective. Direct-to-DOM rendering is completely transparent in the development process.
One of the key features of Direct-to-DOM rendering is the ability to perform incremental changes to the DOM that translate into in-place editing of the page and result in smooth, flicker-free page updates without the need for a full page refresh.
Direct-to-DOM (D2D) rendering is a mechanism that renders a JSF component tree into a W3C standard DOM. When the rendered DOM is cached between JSF lifecyles, it can be used to compute the difference between 2 successive page views, to determine a precise set of DOM changes required to update the page from one view to the next. D2D rendering is core to the
Automatic Ajax feature of the ICEfaces 2.0 framework.
Rendering
When the ICEfaces 2.0 Jar is added to a JSF application, the standard RenderKit is overridden with the ICEfaces RenderKit, and specifically, the ICEfaces RenderKit provides a DomResponseWriter instead of the standard JSF ResponseWriter. The DomResponseWriter diverts the output of any component renderer into a server-side DOM data structure.
DOM Differencing
A newly produced DOM from the D2D rendering process represents the page that will be replicated in the client browser DOM. The cached previous DOM is a replica of the DOM currently in the client browser, so the difference between the two DOMs defines the page updates that need to occur at the client browser. The differencing mechanism performs the basic task of calculating the set of updates to transform one DOM into the next, but the implementation in ICEfaces 2.0 has been highly optimized.
Page Updating
Given the set of page updates from the differencing algorithm, the standard JSF Ajax mechanism is used to deliver and insert those updates into the client DOM, thus completing the JSF lifecyle with D2D rendering.
6. ICEfaces components of our interest
The panelPopup component can be used to display various types of content inside a drag able or modal dialog. These dialogs can be used on pages to display important information and options to the user in a manner similar to a standalone offline application.
The dataTable component can display Objects in a Collection or an Array where each Object represents one row in the table and columns match instance variables in the Object. This mapping is achieved through the JSF attribute iterator pattern of value and var and introspection. The dataTable can limit the number of rows it displays and CSS styles can be applied to both rows and columns.
The auto-complete component is named ice:selectInputText. It provides an inputText component enhanced with the ability to select an option before input has been completed. As the user enters text into the component a pop-up list of possible matching values is provided to the user.
7. ICEfaces advantages and AJAX based features
Automatic Ajax is a mechanism in the ICEfaces framework that calculates precise/minimal page updates from one JSF lifecycle to the next, eliminating the need for standard JSF <f:ajax> tags in the page.
Single Submit provides the ability to submit one component to execute in the JSF lifecycle, and is integral to the Automatic Ajax mechanism in ICEfaces 2. This means that only the specified component will decode, validate, update it's bean model state, and trigger events, but a full render phase will occur. Direct-to-DOM Rendering is then used to determine the set of incremental page updates that must occur in the client browser DOM.
Ajax Push allows the application to incrementally update any part of the page at any time, for any group of clients. This is a small change in terms of the technical capabilities of Ajax applications, but it is a revolutionary change in terms of what applications can actually provide to users. Ajax Push is the key to building collaborative multi-user applications for the web.
8. Problem areas
i) ICEfaces 2 support for Weblogic Portal - NO
ii) Can we use ICEfaces 1.8 with GenericFacesPorltet class in portlet.xml – “NO”
iii) Using D2D in Weblogic portal as per ICEfaces documentation When the ICEfaces JAR is included in your JSF application, the Direct-to-DOM Render Kit is automatically configured into the application. There are no other considerations from the developer perspective. Direct-to-DOM rendering is completely transparent in the development process.
References:
