This document describes how to upgrade your application from QuipuKit 1.x to OpenFaces 2.0.EAP1.

General

• OpenFaces 2.0 requires Java version 5 or higher.
• OpenFaces 2.0 requires JSF 1.2.x (Mojarra or MyFaces).
• As with QuipuKit 1.x, OpenFaces can be used with JSP and Facelets. Though if you are working with Facelets, please ensure that you are using a version 1.1.14 or higher.
• Support for Ajax4jsf framework of versions that existed prior to integrating Ajax4jsf into RichFaces has been dropped. Use RichFaces 3.3.0 or later instead of Ajax4jsf.
• Support for RichFaces library earlier than version 3.3.0 has been dropped. Upgrade to RichFaces 3.3.0 or later.
• Suppor for JBoss Seam framework of versions earlier than 2.0 has been dropped.
• OpenFaces 2.0 comes as a single Jar file named openfaces.jar . License jar file that was required for QuipuKit 1.x is not required anymore and should be removed. Other jar dependencies remained the same (see the Installation and Configuration section in OpenFaces Developer's Guide).

Changes Dependent on the New Product Name

Since version 2.0 QuipuKit has been renamed to OpenFaces. Hence all of the names that depended on the old product name must be changed. Here's the full list of changes that might require updates in your application:

• Renamed the root package from teamdev.jsf to org.openfaces. Therefore you need to update paths to imported packages in your code appropriately. Please also pay special attention to renaming the resource filter class in web.xml from teamdev.jsf.util.ResourceFilter to org.openfaces.util.ResourceFilter . The teamdev.jsf.portlet.QuipuKitPortlet class for configuring portlet applications has also been renamed to org.openfaces.portlet.OpenFacesPortlet.
• Changed prefixes of component-type and component-family strings from teamdev.jsf to org.openfaces .
• The prefixes for application parameters specified in web.xml file were changed from teamdev.jsf to org.openfaces .
• The /qk_internalResource/* resource mapping that can optionally be specified in web.xml for performance optimization has been renamed to /openFacesResources/* .
• Changed validation message key prefixes for message bundles from teamdev.jsf to org.openfaces .
• Namespace for OpenFaces component tags was changed from http://teamdev.com/quipukit  to http://org.openfaces/  . Although it is not required to change the namespace prefix in your page files, we recommend to use the "o" prefix when using OpenFaces tags, for example <o:dataTable>.

Removal of Deprecated API

In version 2.0 we have removed the API that was marked as deprecated in QuipuKit 1.x. Below is the list of changes, with the description of how to retain the appropriate functionality using the new API.

The list of removed attributes, and the appropriate replacements:

The list of removed tags and their replacements:

Renamed, Moved API

Moved/renamed packages:

Moved/renamed classes:

Renamed tags:

Renamed attributes. These are applicable to both property names in the actual component classes and the appropriate attribute names.

Renamed methods:

Client-Side API Changes

The New O$(id) Function

OpenFaces 2.0 introduces a new JavaScript function named "O$(id)" (capital letter O and a dollar sign) that locates a DOM element by its identifier. Locating element by id is a very common scenario, where the "document.getElementById(id)" function is usually invoked. The O$(id) function works in the same way and can be used as a short replacement for this expression. See the documentation for usage example.

Unified Client-Side API

In QuipuKit 1.x each method of component's client-side API was available in two ways:

• As a "global" function prefixed with "q_" and receiving component identifier as the first parameter, for example q_showPopupLayer(popupId);
• As a component instance method without a prefix and component id parameter, for example popup.show().

In OpenFaces 2.0, the first way of using the component's client-side API is not available anymore. Therefore you should replace invocations of all "global" functions, the functions that start with the "q_" prefix, with usages of the appropriate instance methods. We recommend using the new O$(id) function to simplify this process. Here are some examples of replacing the old invocations with the new ones:

Client-Side Validation Functions

Validation functions have undergone a change similar to the one described above. The notation for validation function names was changed. The "q_" prefix was removed, and all functions were placed into the "O$" namespace instead. That means that now you should invoke such functions as methods of the "O$" variable. Here are the examples:

The q_refreshTable and q_refreshTreeTable Functions

In OpenFaces 2.0, the q_refreshTable and q_refreshTreeTable functions were removed in favor of the new API that allows reloading any components and provides a wider set of possibilities. OpenFaces 2.0 introduces the new ReloadComponents component that allows reloading one or more components with Ajax. This component provides programmatic access to its functionality using the O$.reloadComponents function. q_refreshTable and q_refreshTreeTable function invocations should be replaced with O$.reloadComponents invocations as shown below.

The same replacements are applicable for the q_refreshTreeTable function. See the documentation for the ReloadComponents component for more information.

API Changes

Other

<q:confirmation
   closeButtonImageUrl="close.gif"
   ...
/>

<o:confirmation ...>
   <o:captionArea>
     <o:closeWindowButton imageUrl="close.gif"/>
   </o:captionArea>
</o:confirmation>

<q:foldingPanel
  collapsedImageUrl="collapsed.gif"
  expandedImageUrl="expanded.gif"
  buttonHint="Click here"
  buttonPlacement="left" ...>
   ...
</q:foldingPanel>

<o:foldingPanel ...>
   <o:captionArea alignment="left">
     <o:expansionToggleButton
       collapsedImageUrl="collapsed.gif"
       expandedImageUrl="expanded.gif"
       hint="Click here"/>
   </o:captionArea>
   ...
</o:foldingPanel>