Migrar los recursos JavaServer Faces con componentes de cliente Faces

Si creó proyectos en WebSphere Studio V5.1.x que contenían componentes de cliente Faces en JavaServer Faces JavaServer Pages (JSP), debe migrar los recursos de tiempo de ejecución de componentes de cliente Faces a los últimos niveles.

Después de abrir un proyecto en V6.0 que contiene JSP de JavaServer Faces con componentes de cliente Faces creados en WebSphere Studio V5.1.x, debe hacer lo siguiente para migrar los recursos de tiempo de ejecución de componentes de cliente Faces:
  1. Cree un archivo JSP nuevo y para el modelo, seleccione Básico con antememoria de datos del lado del cliente. Este JSP solo se necesita temporalmente para que Rational Application Developer migre todos los archivadores JAR de Java a los últimos niveles.
  2. Se le solicitará que migre los recursos de tiempo de ejecución del proyecto a los últimos niveles. Seleccione para completar el proceso de migración. Importante: si selecciona No o cancela el recuadro de diálogo, los componentes de cliente Faces del proyecto no se migrarán a los últimos niveles y no habrá ninguna otra solicitud al respecto, lo que originará problemas graves entre las herramientas nuevas y los antiguos archivos JAR de tiempo de ejecución.
  3. Después de crear el archivo JSP nuevo, puede suprimirlo del proyecto.
  4. Seleccione objetos de datos en el área de datos de cliente, pulse con el botón derecho y seleccione Configurar. En la pestaña Avanzadas seleccione Regenerar todo para regenerar todos los mediadores.
    Nota: No utilice el botón Regenerar de datos del lado del servidor. Debe utilizar Regenerar todo.
  5. Hay elementos de esquema de Objetos de datos de WebSphere (WDO) de la versión 5.12 que ya no se utilizan en la versión 6.0. Las clases de mediador para estos elementos no se regenerarán y continuarán teniendo errores de compilación. Estos mediadores tendrán el convenio de denominación *_DataGraphSchema_wdo4js_*.java. Suprima estas clases de mediador del proyecto para evitar estos errores de compilación.
Si está trabajando en la plataforma Linux o si está utilizando un entorno local no inglés: antes de seguir los pasos anteriores para migrar los proyectos creados en WebSphere Studio V5.1.x que contengan componentes de cliente Faces en JSP JavaServer Faces, puede recibir el mensaje de error siguiente cuando se cargan los proyectos en V6.0:
El proyecto no puede
construirse porque no se ha podido leer <nombre_clase>.java.
Los archivos no se han podido leer porque las clases de mediador de datos de cliente del proyecto V5.1.x pueden contener caracteres especiales no codificados, mientras que las clases de mediador de Rational Application Developer V6.0 codifican estos caracteres. Estos mensajes de error dejarán de emitirse una vez regenere los datos de cliente siguiendo los pasos descritos anteriormente. Sin embargo, antes de seguir los pasos para migrar los proyectos que contengan componentes de cliente Faces debe suprimir los archivos de mediador de datos de cliente del proyecto cargado en V6.0 para poder construir el área de trabajo. Para suprimir los archivos de mediador de datos de cliente:
  1. Suprima del proyecto todos los paquetes de clase de mediador de datos de cliente que tengan el convenio de denominación com.ibm.dynwdo4jsmediators.<client-data-name>.
  2. NO suprima el paquete llamado com.ibm.dynwdo4jsmediators. Este paquete contiene metadatos (archivos ecore y emap) para los datos de cliente del proyecto que se utilizarán para regenerar los mediadores.
  3. Después de suprimir los paquetes de mediador, se construirá el proyecto. Ahora puede completar los pasos de migración descritos anteriormente.

En algunos casos recibirá un mensaje indicando que la generación del mediador ha fallado. Para corregir este problema, edite el archivo OdysseyBrowserFramework.properties, suprima las entradas de las propiedades EMAP_FILES y ECORE_FILES y vuelva a intentarlo.

Nota: Los problemas pueden producirse al cambiar el servidor destino de un proyecto que contenga componentes de cliente Faces de WebSphere Application Server V5.1 a V6.0.
Hay dos problemas que pueden producirse al cambiar el servidor destino de un proyecto que contenga componentes de cliente Faces de WebSphere Application Server V5.1 a V6.0:
  • Las clases de mediador de datos de cliente que ya se hayan generado no se compilarán más. Deben regenerarse un JSP a la vez. Esto se hace de la forma siguiente:
    1. Abra el archivo OdysseyBrowserFramework.properties que se encuentra en la carpeta origen Java raíz. Guarde el contenido para utilizarlo posteriormente.
    2. En el archivo OdysseyBrowserFramework.properties, para cada JSP que contenga datos de cliente Faces en el proyecto, busque las entradas <client-data-name>.ecore y <client-data-name>.emap para las propiedades EMAP_FILES y ECORE_FILES.
    3. Guarde solo las entradas coincidentes para los datos de cliente en el JSP y suprima el resto de entradas.
      Por ejemplo, si la página actual tiene datos de cliente llamados ACCOUNT y el archivo de propiedades tenía una entrada como esta:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
      debe suprimir com\\ibm\\dynwdo4jsmediators/orders.emap de la entrada. La entrada tendrá ahora el aspecto siguiente:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
    4. Guarde el archivo de propiedades.
    5. Pulse el botón derecho del ratón sobre los datos de cliente en el JSP y seleccione Configurar.
    6. Seleccione la pestaña Avanzadas. Pulse el botón Regenerar todo. Esto regenerará todos los artefactos necesarios para todos los datos de cliente en el JSP actual.
    7. Repita estos pasos para cada JSP que contenga datos de cliente en el proyecto.

    Después de regenerar las clases de mediador de datos de cliente para los JSP en el proyecto, quedarán algunas clases de mediador que no compilarán. Se trata de mediadores para elementos de esquema que ya no se utilizan en Objetos de datos de servicio (SDO) en V6.0. Estos mediadores tendrán el convenio de denominación *_DataGraphSchema_wdo4js_*.java y *_RootDataObject_wdo4js_*.java. Suprima estas clases de mediador del proyecto para evitar estos errores de compilación.

    Una vez que la migración se haya realizado satisfactoriamente, restaure el contenido original del archivo OdysseyBrowserFramework.properties.

  • Los componentes de cliente Faces de vista de árbol enlazados a los WDO no pueden ejecutarse en el servidor después de cambiar el servidor destino del proyecto a WebSphere Application Server V6.0.
    La solución para esto consiste en modificar la vista del fuente del JSP para cambiar todos los códigos de className para que utilicen la clase DataObject de SDO en lugar de la clase DataObject de WDO. Por ejemplo, para un WDO llamado account:
    1. Para el objeto raíz, cambie el código className de className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" a className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
    2. Para todos los nodos hijo, cambie el código className de className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" a className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)", donde ACCOUNT es el nombre del nodo de datos.
Actualizar a los manejadores y procesadores Diff automatizados: Los procesadores y los manejadores Diff se generan ahora automáticamente. Si escribió manejadores y procesadores Diff para los componentes de cliente Faces en WebSphere Studio V5.1.x, es recomendable descartar ese código y utilizar los procesadores y manejadores generados automáticamente. Para hacerlo, debe seguir los pasos siguientes:
  1. Genere los manejadores y procesadores Diff nuevos. Para hacerlo, en cada Objeto de datos de cliente del proyecto, debe hacer lo siguiente:
    1. Seleccione el Objeto de datos de cliente, pulse con el botón derecho del ratón y seleccione Configurar.
    2. En la pestaña Avanzadas, seleccione Regenerar todo.
  2. Elimine el código escrito para invocar los procesadores y manejadores Diff ya que los procesadores y manejadores generados se invocan automáticamente. Por ejemplo, este código se utiliza para el evento Command para el componente de botón de mandato. A continuación se proporciona un ejemplo del aspecto que tendría el código:
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. Elimine del proyecto los archivos que corresponden a los manejadores y procesadores personalizados creados.
Mantener los manejadores y procesadores Diff personalizados escritos para V5.1.x: aunque esto no es recomendable, si decide que debe mantener los manejadores y procesadores Diff de V5.1.x, deberá modificarlos para que funcionen en V6.0 ya que la interfaz DiffHandler y la clase DiffInfo han cambiado.
  • La interfaz DiffHandler ha cambiado de la manera siguiente:
    • El método handle ahora lanza Exception además de DiffException.
    • El método find nuevo lo utiliza la infraestructura para buscar objetos.
    • El método getId nuevo se utiliza para depurar y permite que la infraestructura imprima el valor de un objeto.

    Los métodos find y getId los utilizan internamente los DiffHandler generados. Para los DiffHandler personalizados puede implementar métodos vacíos para que se ajusten a la interfaz. La infraestructura llamará ahora a estos métodos.

    La interfaz DiffHandler es ahora:
    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);
     }
  • La clase DiffInfo ha cambiado de la forma siguiente:
    • El método ArrayList getAncestors() se ha sustituido por el método DiffInfo getParent() que proporciona una forma más fácil de acceder a la información para cada objeto en el árbol de ancestros de forma recursiva.
    • Los métodos getCurrent() y getOriginal() ahora devuelven un objeto DataObject en lugar de un objeto EObject. No es obligatorio que cambie el código para utilizar el objeto DataObject. Sin embargo, la interfaz DataObject es más fácil y más intuitiva de utilizar que EObject. Puede convertir temporalmente un objeto DataObject en un objeto EObject fácilmente para el código heredado.
    • Se ha añadido un método getPropertyName() de String nuevo para identificar el nombre de propiedad al que se aplica este objeto. Esto es importante si, por ejemplo, una clase dada tiene dos propiedades del mismo tipo. Anteriormente en la clase DiffInfo el código no hubiera podido diferenciar entre ambas propiedades.
    La clase DiffInfo es ahora:
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    Nota: La clase DiffInfo ya no está soportada para uso público ya que los procesadores y manejadores Diff se generan automáticamente. Mantener los manejadores antiguos solo es una solución temporal y se aconseja encarecidamente que se utilicen los manejadores automatizados.
Cambios en los componentes de cliente Faces en V6.0:
  • Soporte para WebSphere Application Server V6.0.
  • Soporte para Objetos de datos de servicio (SDO) en WebSphere Application Server V6.0.
  • Los datos EGL se soportan ahora como datos de cliente.
  • Los procesadores Diff y los manejadores se generan automáticamente.
  • Hay eventos nuevos para los componentes de cliente siguientes:
    • TabbedPanel: onInitialPageShow
    • Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
    • DataGrid: onPage, onSort, onFilter

Tema principal: Migrar de WebSphere Studio V5.1, V5.1.1 o V5.1.2

Tareas relacionadas
Migrar los recursos JavaServer Faces de un proyecto Web
Migrar los recursos Faces de un proyecto portlet

Condiciones de uso | Comentarios
(C) Copyright IBM Corporation 2000, 2005. Reservados todos los derechos.