Migration de ressources JavaServer Faces avec des composants Faces Client

Si vous créez des projets dans WebSphere Studio V5.1.x contenant des composants Faces Client dans des pages JSP (JavaServer Pages) JavaServer Faces, vous devez migrer les ressources d'exécution des composants Faces Client vers les derniers niveaux.

Après l'ouverture dans un projet V6.0 contenant des pages JSP JavaServer Faces avec des composants Faces Client dans WebSphere Studio V5.1.x, vous devez suivre la procédure ci-après afin de migrer les ressources d'exécution des composants Faces Client.
  1. Créez un fichier JSP et pour le modèle, sélectionnez De base avec mise en cache des données côté client. Cette page JSP est nécessaire uniquement de manière temporaire afin de faire en sorte que Rational Application Developer migre tous les fichiers JAR (Java archive) système vers les derniers niveaux.
  2. Un message s'affiche indiquant que vous pouvez migrer les ressource d'exécution du projet vers les derniers niveaux. Sélectionnez Oui pour mettre fin au processus de migration. Important : Si vous sélectionnez Non ou que vous fermez la boîte de dialogue, les composants Faces Client du projet seront migrés vers les derniers niveaux et aucune invite ne s'affiche à nouveau. Cette migration génère des erreurs importantes entre les nouveaux outils et les anciens fichiers JAR d'exécution.
  3. Après la création du fichier JSP, vous pouvez le supprimer du projet.
  4. Sélectionnez un objet de données dans la zone Données client, cliquez avec le bouton droit de la souris et sélectionnez Configurer. Dans l'onglet Avancé, sélectionnez Tout actualiser. Ainsi, tous les médiateurs sont actualisés.
    Remarque : N'utilisez pas le bouton permettant d'effectuer une regénération à partir des données côté serveur. Vous devez utiliser le bouton Tout actualiser.
  5. Il existe des éléments de schéma WDO (WebSphere Data Objects) dans la version 5.12 qui ne sont plus utilisés dans la version 6.0. Les classes du médiateur de ces éléments ne sont pas regénérées et des erreurs de compilation se produisent toujours. Ces médiateurs utilisent la convention de dénomination *_DataGraphSchema_wdo4js_*.java. Supprimez ces classes de médiateur du projet afin d'éviter ces erreurs de compilation.
Si vous utilisez la plateforme Linux ou si vous utilisez un environnement local qui n'est pas en anglais : Avant de suivre la procédure décrite ci-dessus pour migrer les projets créés dans WebSphere Studio V5.1.x contenant des composants Faces Client dans des pages JSP JavaServer Faces, le message d'erreur suivant peut s'afficher lorsque les projets sont chargés dans la version 6.0 :
Les projets ne peuvent pas être générés
car le fichier <classe_nom>.java ne peut pas être lu.
Les fichiers ne peuvent pas être lus car les classes de médiateur Données client du projet V5.1.x peuvent contenir des caractères spéciaux qui ne sont pas codés alors que les classes de médiateur de Rational Application Developer V6.0 codent ces caractères. Ces messages d'erreur n'apparaissent plus après la regnération des données client en suivant la procédure décrite ci-dessous. Toutefois, avant de suivre la procédure permettant de migrer le projet contenant les composants Faces Client, vous devez tout d'abord supprimer les fichiers de médiateur de données client du projet chargé dans la version 6.0 afin que l'espace de travail puisse être généré. Pour supprimer les fichiers de médiateur des données client, procédez comme suit :
  1. Supprimez tous les packages de classe de médiateur de données client qui utilisent la convention de dénomination com.ibm.dynwdo4jsmediators.<client-données-nom> du projet.
  2. NE SUPPRIMEZ PAS le package nommé com.ibm.dynwdo4jsmediators. Ce package contient des métadonnées (fichiers ecore et emap) pour les données client du projet qui seront utilisées pour la regénération des médiateurs.
  3. Après la suppression des packages de médiateur, votre projet sera généré. Vous pouvez maintenant suivre la procédure de migration décrite ci-dessus.

Dans certains cas, un message indiquant que la génération du médiateur n'a pas abouti peut s'afficher. Pour corriger ce problème, modifiez le fichier OdysseyBrowserFramework.properties et supprimez les entrées des propriétés EMAP_FILES et ECORE_FILES et faites une nouvelle tentative.

Remarque : Des problèmes peuvent survenir lors de la modification du serveur cible d'un projet contenant des composants Faces Client de WebSphere Application Server V5.1 en V6.0.
Deux problèmes peuvent survenir lors de la modification du serveur cible d'un projet contenant des composants Faces Client de WebSphere Application Server V5.1 en V6.0 :
  • Les classes du médiateur de données client déjà générées ne seront plus compilées. Chaque page JSP doit être regénérée séparément. Cette opération est effectuée de la manière suivante :
    1. Ouvrez le fichier OdysseyBrowserFramework.properties se trouvant à la racine du dossier source Java. Sauvegardez le contenu pour une utilisation ultérieure.
    2. Dans le fichier OdysseyBrowserFramework.properties, pour chaque page JSP contenant des données Faces Client dans le projet, recherchez les entrées <client-données-nom>.ecore et <client-données-nom>.emap pour les propriétés EMAP_FILES et ECORE_FILES.
    3. Conservez uniquement les entrées correspondantes pour les données client de la page JSP et supprimez toutes les autres entrées.
      Par exemple, si des données client portent le nom ACCOUNT dans la page en cours et que le fichier des propriétés dispose d'une entrée du type :
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
      Vous devez supprimer com\\ibm\\dynwdo4jsmediators/orders.emap de l'entrée. L'entrée doit maintenant avoir l'aspect suivant :
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
    4. Sauvegardez le fichier properties.
    5. Cliquez à l'aide du bouton droit de la souris sur Données client sur la page JSP et sélectionnez Configurer.
    6. Sélectionnez l'onglet Avancé. Cliquez sur le bouton Tout actualiser. Cette action permet de regénérer tous les artefacts nécessaires aux données client de la page JSP en cours.
    7. Renouvelez cette étape pour chaque page JSP contenant des données client du projet.

    Après la regénération des classes de médiateur de données client pour les pages JSP du projet, certaines classes du médiateur ne seront pas compilées. Il s'agit des médiateurs des éléments de schéma qui ne sont plus utilisés dans SDO (Service Data Object) dans la version 6.0. Ces médiateurs utilisant la convention de dénomination *_DataGraphSchema_wdo4js_*.java et *_RootDataObject_wdo4js_*.java. Supprimez ces classes de médiateur du projet afin d'éviter ces erreurs de compilation.

    Après la migration, restaurez le contenu d'origine du fichier OdysseyBrowserFramework.properties.

  • L'exécution des composants Faces Client de la vue Arborescence associés à WDO n'a pas abouti sur le serveur après la modification du serveur cible du projet en WebSphere Application Server V6.0.
    Pour éviter cette situation, il suffit de modifier la vue source de la page JSP afin de modifier toutes les balises className afin d'utiliser la classe SDO DataObject à la place de la classe DataObject WDO. Par exemple, pour un objet WDO nommé account :
    1. Pour l'objet racine, modifiez la balise classNameclassName="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" en className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
    2. Pour tous les noeuds enfant, modifiez la balise className className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" en className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)", où ACCOUNT correspond au noeud de données.
Mise à niveau vers les processeurs et les gestionnaires Diff : Les gestionnaires et les processeurs Diff sont maintenant automatiquement générés. Si vous concevez des processeurs et des gestionnaires Diff pour les composants Faces Client dans WebSphere Studio V5.1.x, il est recommandé d'ignorer ce code et d'utiliser les processeurs et les gestionnaires automatiquement générés. Pour cela, vous devez suivre la procédure ci-après.
  1. Générez les nouveaux processeurs et gestionnaires Diff. Vous devez alors suivre la procédure ci-après pour chaque objet de données du projet.
    1. Sélectionnez l'objet de données client. Cliquez avec le bouton droit de la souris et sélectionnez Configurer.
    2. Sur l'onglet Avancé, sélectionnez Tout actualiser.
  2. Supprimez le code que vous avez généré pour appeler les processeurs et les gestionnaires Diff, les processeurs et les gestionnaires générés étant appelés automatiquement. Un exemple classique de l'emplacement d'utilisation de ce code concerne l'événement Commande du composant de bouton de commande. Ci-dessous, se trouve un exemple de l'aspect du code :
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. Supprimez du projet les fichiers correspondant aux anciens processeurs et gestionnaires personnalisés que vous avez créés.
Conservation des processeurs et des gestionnaires Diff personnalisés conçus pour la version 5.1.x : Bien que cette action ne soit pas recommandée, si vous décidez de conserver les processeurs et les gestionnaires Diff personnalisés de la version 5.1.x, il est nécessaire de les modifier afin qu'ils fonctionnent dans la version 6.0 étant donné que l'interface DiffHandler et la classe DiffInfo ont été modifiées.
  • Voici les modifications apportées à l'interface DiffHandler :
    • La méthode du gestionnaire émet maintenant Exception outre DiffException.
    • L'infrastructure utilise la nouvelle méthode de localisation pour trouver des objets.
    • La nouvelle méthode getId permet le débogage et permet également à l'infrastructure d'imprimer la valeur d'un objet.

    Les méthodes getId et de localisation sont utilisées en interne par les éléments DiffHandler générés. Pour les éléments DiffHandler personnalisés, vous pouvez implémenter des méthodes vides pour la compatibilité avec l'interface. Ces méthodes ne sont pas appelées par l'infrastructure.

    L'interface DiffHandler est maintenant la suivante :
    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);
     }
  • Voici les modifications apportées à la classe DiffInfo :
    • La méthode ArrayList getAncestors() a été remplacée par la méthode DiffInfo getParent(), qui permet d'accéder plus facilement aux informations de chaque objet de l'arborescence des ancêtres de manière récursive.
    • Les méthodes getCurrent() et getOriginal() renvoient maintenant un objet DataObject à la place d'un objet EObject. Il n'est pas obligatoire de changer le code pour utiliser l'objet DataObject. Toutefois, l'utilisation de l'interface DataObject est plus simple et plus intuitive que celle de l'objet EObject. Vous pouvez facilement transtyper un objet DataObject en un objet EObject pour le code existant.
    • Une nouvelle chaîne de méthodes getPropertyName() a été ajoutée pour l'identification du nom de propriété auquel s'applique cet objet. Cet ajout est important si, par exemple, une classe donnée a deux propriétés du même type. Précédemment, dans la classe DiffInfo, le code n'aurait pas pu effectuer la différence entre les deux propriétés.
    La classe DiffInfo est maintenant la suivante :
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    Remarque : La classe DiffInfo n'est plus prise en charge pour l'utilisation publique et les gestionnaires et les processeurs Diff sont maintenant automatiquement générés. La conservation des anciens gestionnaires n'est qu'une solution temporaire et il est fortement recommandé d'utiliser des gestionnaires automatisés.
Voici les modifications apportées aux composants Faces Client dans la version 6.0 :
  • Prise en charge de WebSphere Application Server V6.0.
  • Prise en charge de SDO (Service Data Objects) sur WebSphere Application Server V6.0.
  • Les données EGL sont maintenant prises en charge comme données client.
  • Les gestionnaires et processeurs Diff sont automatiquement générés.
  • Il existe de nouveaux événements pour les composants Client suivants :
    • TabbedPanel : onInitialPageShow
    • Tree : onNodeExpand, onNodeCollapse, onExpand, onCollapse
    • DataGrid : onPage, onSort, onFilter

Sujet parent : Migration à partir de WebSphere Studio V5.1, 5.1.1 ou 5.1.2

Tâches associées
Migration de ressources JavaServer Faces dans un projet Web
Migration de ressources Faces dans un projet de portlet

Conditions d'utilisation | Commentaires
(C) Copyright IBM Corporation 2000, 2005. All Rights Reserved.