Migrating JavaServer Faces resources with Faces Client Components

If you created projects in WebSphere Studio V5.1.x containing Faces Client Components in JavaServer Faces JavaServer Pages (JSPs), migrate the runtime resources of the Faces Client Components to the latest levels.

After opening in V6.0 a project containing JavaServer Faces JSPs with Faces Client Components created in WebSphere Studio V5.1.x, do the following in order to migrate the runtime resources of Faces Client Components:

1. Create a new JSP file, and for the model select Basic with client-side data caching. This JSP is only needed temporarily in order to cause Rational Web Developer to migrate all the system Java archive (JAR) files to the latest levels.

2. You will be prompted that you can migrate the project runtime resources to the latest levels. Select Yes to complete the migration process. Important: If you select No, or cancel the dialog box, your project's Faces Client Components will not be migrated to the latest levels and you will not get prompted again, causing several serious issues between the new tooling and the old runtime JAR files.

3. After creating the new JSP file, you can delete it from the project.

4. Select any data object in the Client Data area, right click and select Configure. On the Advanced tab select Regenerate All, which will regenerate all your mediators.

   Note: Do not use the Regenerate from server-side data button. You must use Regenerate All.

5. There are WebSphere Data Objects (WDO) schema elements in version 5.12 that are no longer used in version 6.0. The mediator classes for these elements will not be regenerated and will continue to have compile errors. These mediators will have the naming convention *_DataGraphSchema_wdo4js_*.java. Delete these mediator classes from your project to prevent these compile errors.

Note: Prior to following the steps described above to migrate your projects created in WebSphere Studio V5.1.x containing Faces Client Components in JavaServer Faces JSPs, if you are using a non-English locale, you may see error messages such as failed to build project <name> because class/file <classname> could not be read when the projects are loaded into V6.0. These error messages will stop once you regenerate your client-data by following the steps described above.

Upgrading to automated Diff handlers and processors: Diff processors and handlers are now automatically generated. If you wrote Diff handlers and processors for your Faces Client Components in WebSphere Studio V5.1.x, it is recommended that you discard that code and use the automatically generated processors and handlers. To do so, you need to do the following steps:

1. Generate the new Diff handlers and processors. To do so, on each Client Data Object in your project do the following:
   1. Select the Client Data Object, right-click and select Configure.

   2. On the Advanced tab, select Regenerate All.

2. Remove the code you wrote to invoke your Diff processor and handlers, since the generated processors and handlers are invoked automatically. A typical example of where this code was used would be for the Command event for the Command Button component. The following is an example of how the code might look:

   String Diff = getClientData1().getDiffStr();
   if (DiffProcessor.Synch(getRoot(), Diff) == true)
    return "";
   return "failure";

3. Remove from your project the files corresponding to the old custom handlers and processors you created.

Keeping custom Diff handlers and processors written for V5.1.x: Although this is not recommended, if you decide you need to keep your custom Diff handlers and processors from V5.1.x, they will need to be modified in order to work in V6.0, as the DiffHandler interface and DiffInfo class have changed.

• The DiffHandler interface has changed as follows:
  • The handle method now throws Exception in addition to DiffException.

  • The new find method is used by the framework to find objects.

  • The new getId method is used for debugging and allows the framework to print the value of an object.

  The find and getId methods are used internally by the generated DiffHandlers. For your custom DiffHandlers, you can implement empty methods just to comply with the interface. Those methods will not be called by the framework.

  The DiffHandler interface is now:

  public interface DiffHandler
   {
     public void   handle(DiffInfo Diff) throws DiffException, Exception;
     public Object find  (DiffInfo Diff) throws DiffException, Exception;
     public String getId (DiffInfo Diff, boolean Original);
   }

• The DiffInfo class has changed as follows:
  • The method ArrayList getAncestors() has been replaced by the method DiffInfo getParent(), which provides an easier way to access the information for each object in the ancestor tree in a recursive manner.

  • The methods getCurrent() and getOriginal() now return a DataObject object instead of an EObject object. It is not mandatory that you change your code to use the DataObject object. However, the DataObject interface is much easier and more intuitive to use than EObject. You can easily cast a DataObject object to an EObject object for legacy code.

  • A new method String getPropertyName() was added to identify the property name for which this object applies. This is important if, for example, a given class has two properties of the same type. Previously in the DiffInfo class, the code would have been unable to differentiate between the two properties.

  The DiffInfo class is now:

  public class DiffInfo
   {
     public char       getCrud()
     public DataObject getCurrent()
     public String     getEClassName()
     public DataObject getOriginal()
     public String     getPropertyName()
     public DiffInfo   getParent()
   }

  Note: The DiffInfo class is no longer supported for public use as Diff processors and handlers are now automatically generated. Keeping your old handlers is only a temporary solution and it is strongly advised that automated handlers be used.

Changes to Faces Client Components in V6.0:

• Support for WebSphere Application Server V6.0.

• Support for Service Data Objects (SDO) on WebSphere Application Server V6.0.

• EGL data is now supported as client data.

• Diff processors and handlers are automatically generated.

• There are new events for the following Client Components:
  • TabbedPanel: onInitialPageShow

  • Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse

  • DataGrid: onPage, onSort, onFilter

 

Parent topic

Migrating from WebSphere Studio V5.1, 5.1.1, or 5.1.2

 

Related tasks

Migrating Faces resources in a portlet project