The JavaServer Faces Client runtime resources that originally shipped
in WebSphere® Studio
Application Developer V5.1.x have
been updated for Rational® Application
Developer V6.0.1.
If you want to continue development on Web projects that were created with
this previous product version, it is recommended that you update the Faces
Client runtime resources to the latest levels.
In Rational Application
Developer V6.0.1,
the Faces Client runtime resource updates happen automatically when a Web
project is imported or a workspace is opened that contains out-of-date resources.
After importing a Web project or opening a workspace from WebSphere Studio
Application Developer V5.1.x
to Rational Application
Developer V6.0.1, you
will be prompted to update the Faces Client runtime resources to the latest
levels.
Automatically updating runtime resources
To update
the Faces Client runtime resources
automatically for a Web project:
- Import a Web project (or a workspace) containing Faces Client content
from WebSphere Studio
Application Developer V5.1.x. The
Project Migration window opens.
Note: If the Project Migration window does
not open, your automatic build preference setting is probably disabled. In
Project Explorer, right-click your Web project and select ; the process of rebuilding a
project opens the Project Migration window.
- If you have other Web projects with Faces Client content in your workspace,
check Apply this choice to any other projects that need to be upgraded and
all your Web projects will be updated.
- Click one of the following:
- Yes to complete the update automatically.
- Later to defer the update. To update runtime resources
automatically after selecting Later, you have to close and reopen the
Web project or restart the workbench before rebuilding your Web project. If
you have disabled automatic builds, right-click your Web project and select Build
Project.
- Never to keep your runtime resources back-level.
If you choose Never and intentionally stay with the
back-level runtime resources, you will not be prompted again to update them.
In the future, you will need to update the runtime resources manually if you
require them.
- From the folder in your Web project, delete all client data mediator
class packages with the naming convention com.ibm.dynwdo4jsmediators.<client-data-name>.
Do not delete the package named com.ibm.dynwdo4jsmediators. This package
contains metadata (ecore and emap files) for the client data in your project
that will be used to regenerate the mediators.
- From the folder in your Web project, open the OdysseyBrowserFramework.properties
file and delete the entries for EMAP_FILES and ECORE_FILES.
- For each data object in the Client Data view:
- Right-click and select Configure.
- On the Advanced tab, click Regenerate
from server-side data to regenerate all mediators for the data
object.
Manually updating runtime resources
To update the Faces
Client runtime resources
manually for a Web project:
- Complete the Manually updating runtime resources steps in Updating Faces runtime resources in a Web project.
- Complete steps 4-6 of the Automatically updating runtime
resources section above.
Problems may occur when changing the target server of a project
containing Faces Client components from WebSphere Application Server V5.1
to V6.0.
There are two problems that may occur when changing the
target server of a project containing Faces Client components from WebSphere Application
Server V5.1 to V6.0:
- Client data mediator classes that have already been generated will no
longer compile. They need to be regenerated one JSP at a time::
- Open the OdysseyBrowserFramework.properties file found in the root Java™ source
folder. Save the contents for future use.
- In the OdysseyBrowserFramework.properties file, for each JSP in your Web
project containing Faces client data, find the <client-data-name>.ecore
and <client-data-name>.emap entries for properties EMAP_FILES and ECORE_FILES.
- Keep only the matching entries for the client data on your JSP, and delete
all other entries.
For example, if your current page has a Client Data called
ACCOUNT, and your properties file had entry like:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
you should delete
com\\ibm\\dynwdo4jsmediators/orders.emap from
the entry. The entry would now appear as:
EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
- Save the properties file.
- Select a client data object in a JSP then right-click and select Configure.
- On the Advanced tab, click Regenerate
All. This will regenerate all the artifacts needed for all client
data on the current JSP.
- Repeat these steps 2-6 for each JSP containing client data in your Web
project.
- After regenerating the client data mediator classes, there will still
be some mediator classes left that will not compile. These are mediators for
schema elements no longer used in Service Data Objects (SDOs) in V6.x and
have the naming convention *_DataGraphSchema_wdo4js_*.java and *_RootDataObject_wdo4js_*.java.
Delete these mediator classes from your Web project to prevent these compile
errors.
- After the update completes successfully, restore the original contents
of the OdysseyBrowserFramework.properties file.
- Tree view Faces Client components bound to WDOs fail to run on the server
after changing the project's target server to WebSphere Application Server V6.0.
The workaround is to modify the source view of your JSP to change all className
tags to use SDO DataObject class instead of WDO DataObject class. For example,
for a WDO named account:
- For the root object, change the className tag from className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" to className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
- For all child nodes, change the className tag from className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" to className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)", where
ACCOUNT is the name of the data node.
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:
- Generate the new Diff handlers and processors on each client data object
in your Web project.
- Select the client data object, right-click and select Configure.
- On the Advanced tab, click Regenerate
All.
- 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, as such:
String Diff = getClientData1().getDiffStr();
if (DiffProcessor.Synch(getRoot(), Diff) == true)
return "";
return "failure";
- Remove the files corresponding to the old custom handlers and processors
you created from your Web project.
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 existing 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 components:
- TabbedPanel: onInitialPageShow
- Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
- DataGrid: onPage, onSort, onFilter