Migrazione delle risorse JavaServer Faces con i componenti Faces Client

Se sono stati creati progetti in WebSphere Studio V5.1.x contenenti componenti client Faces nelle JSP (JavaServer Faces JavaServer Pages), sarà necessario migrare le risorse di runtime dei componenti client agli ultimi livelli.

Dopo aver aperto in V6.0 un progetto contenente JSP JavaServer Faces con i componenti client Faces creati in WebSphere Studio V5.1.x, sarà necessario procedere come segue per migrare le risorse di runtime dei componenti client Faces:
  1. Creare un nuovo file JSP e per il modello selezionare Base con cache di dati client-side. Questa JSP è richiesta solo temporaneamente per far sì che Rational Application Developer migri tutti i file system JAR (Java agli ultimi livelli.
  2. Verrà richiesto di migrare le risorse di runtime del progetto agli ultimi livelli. Selezionare per completare il processo di migrazione. Importante: se si seleziona No o si chiude la finestra, i componenti client Faces del progetto non verranno migrati all'ultimo livello e non verrà richiesto nuovamente, causando così il verificarsi di diversi problemi tra la nuova strumentazione e i vecchi file JAR di runtime.
  3. Dopo aver creato il nuovo file JSP, sarà possibile eliminarlo dal progetto.
  4. Selezionare qualsiasi oggetto dati nell'area Dati client, fare clic con il tasto destro del mouse e selezionare Configura. Nella scheda Avanzate, selezionare Rigenera tutto, in modo da rigenerare tutti i mediatori.
    Nota: Non utilizzare il pulsante Rigenera dai dati del server. È necessario utilizzare Rigenera tutto.
  5. La versione 5.12 si WebSphere contiene alcuni elementi di schema Data Objects (WDO) non più utilizzati nella versione 6.0. Le classi di mediazione per questi elementi non verranno rigenerate e continueranno ad avere errori di compilazione. Tali mediatori utilizzano la convenzione di denominazione *_DataGraphSchema_wdo4js_*.java. Eliminare queste classi di mediazione dal progetto per prevenire tali errori di compilazione.
Se si utilizza la piattaforma Linux, o se si utilizzano impostazioni internazionali non inglesi, procedere come segue: prima di seguire le istruzioni riportate precedentemente per migrare i progetti creati in WebSphere Studio V5.1.x contenenti i componenti client Faces nelle JSP JavaServer Faces, è possibile che venga visualizzato un messaggio di errore simile al seguente durante il caricamento dei progetti in V6.0:
Impossibile generare i progetti perché non è stato
possibile leggere <class_name>.java. 
Non è stato possibile leggere i file perché probabilmente le classi del mediatore Dati client nel progetto V5.1.x contengono caratteri speciali non codificati, laddove le classi del mediatore in Rational Application Developer V6.0 codificano tali caratteri. Questi messaggi di errore verranno arrestati una volta aver generato i dati client attenendosi alle istruzioni riportate in precedenza. Tuttavia, prima di procedere con la migrazione dei progetti contenenti i componenti client Faces, sarà necessario prima eliminare i file del mediatore dei dati client dal progetto caricato in V6.0 in modo che sia possibile generare lo spazio di lavoro. Per eliminare i file del mediatore dei dati client, procedere come segue:
  1. Eliminare dal progetto tutti i pacchetti della classe di mediazione dati client denominati in base alla convenzione com.ibm.dynwdo4jsmediators.<client-data- name>.
  2. NON eliminare il pacchetto com.ibm.dynwdo4jsmediators. Questo pacchetto contiene metadati (file ecore ed emap) per i dati client nel progetto che verranno utilizzati per rigenerare i mediatori.
  3. Dopo aver eliminato i pacchetti del mediatore, il progetto verrà generato. A questo punto è possibile completare le operazioni di migrazione descritte in precedenza.

In alcune istanze, è possibile che venga visualizzato il messaggio generazione mediatore non riuscita. Per correggere questo problema, modificare il file OdysseyBrowserFramework.properties, eliminare le voci per le proprietà EMAP_FILES e ECORE_FILES e tentare nuovamente.

Nota: È possibile che possano verificarsi dei problemi durante la modifica del server di destinazione di un progetto contenente componenti client Faces da WebSphere Application Server V5.1 a V6.0.
Inoltre, possono verificarsi due problemi durante la modifica del server di destinazione di un progetto contenente componenti client Faces da WebSphere Application Server V5.1 a V6.0:
  • Le classi del mediatore dati client già generate non verranno più compilate. Dovranno essere rigenerate con una JSP alla volta. Procedere come segue:
    1. Aprire il file OdysseyBrowserFramework.properties trovato nella cartella principale dell'origine Java. Salvare il contenuto affinché possa essere utilizzato in seguito.
    2. Nel file OdysseyBrowserFramework.properties, per ciascuna JSP contenente dati client Faces nel nuovo progetto, trovare le voci <client-data-name>.ecore e <client-data-name>.emap per le proprietà EMAP_FILES e ECORE_FILES.
    3. Mantenere solo le voci corrispondenti per i dati client nel JSP ed eliminare tutte le altre voci.
      Ad esempio, se la pagina corrente contiene i dati client ACCOUNT e il file delle proprietà ha una voce simile a:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap com\\ibm\\dynwdo4jsmediators/orders.emap
      eliminare com\\ibm\\dynwdo4jsmediators/orders.emap da questa voce. La voce verrà visualizzata come:
      EMAP_FILES=com\\ibm\\dynwdo4jsmediators/account.emap
    4. Salvare il file delle proprietà.
    5. Selezionare i dati client con il tasto destro del mouse nella JSP e selezionare Configura.
    6. Selezionare la scheda Avanzate. Scegliere Rigenera tutto. In tal modo tutte le risorse necessarie per tutti i dati client nella JSP corrente verranno rigenerati.
    7. Ripetere questi punti per ciascun JSP contenente i dati client nel progetto.

    Dopo aver rigenerato le classi del mediatore dati client per le JSP nel progetto, saranno presenti ancora alcune classi di mediatore non compilate. Esistono mediatori per gli elementi dello schema non più utilizzati negli SDO (Service Data Objects) in V6.0. Questi mediatori utilizzano la condizione di denominazione *_DataGraphSchema_wdo4js_*.java e *_RootDataObject_wdo4js_*.java. Eliminare queste classi di mediazione dal progetto per prevenire tali errori di compilazione.

    Dopo aver completato correttamente la migrazione, ripristinare il contenuto originale del file OdysseyBrowserFramework.properties.

  • I componenti client Faces della vista ad albero associati a WDO non possono essere eseguiti sul server dopo aver modificato il server di destinazione del progetto in WebSphere Application Server V6.0.
    La soluzione consiste nel modificare la vista Origine della JSP in modo da cambiare tutti i tag className affinché utilizzino una classe SDO DataObject invece della classe WDO DataObject. Ad esempio, per un WDO chiamato account:
    1. Per l'oggetto principale, modificare il nome del tag className da className="com.ibm.etools.wdo.DataObject(DynWDO`account`RootDataObject)" in className="commonj.sdo.DataObject(DynWDO`account`DataGraphRoot)".
    2. Per tutti i nodi secondari, modificare il tag className da className="com.ibm.etools.wdo.DataObject(DynWDO`account`ACCOUNT)" a className="commonj.sdo.DataObject(DynWDO`account`ACCOUNT)", dove ACCOUNT è il nome del nodo di dati.
Aggiornamento ai processori e gestori Diff automatici: i processori e i gestori Diff vengono generati automaticamente. Se i processori e i gestori Diff per i componenti del client Faces sono stati scritti in WebSphere Studio V5.1.x, si consiglia di eliminare il codice e di utilizzare i gestori e i processori generati automaticamente. Per effettuare questa operazione, è necessario procedere come segue:
  1. Generare i nuovi gestori e processori Diff. Per effettuare questa operazione, per ciascun oggetto dati client del progetto, procedere come segue:
    1. Selezionare l'oggetto dati client con il tasto destro del mouse e selezionare Configura.
    2. Nella scheda Avanzate, selezionare Rigenera tutto.
  2. Rimuovere il codice scritto per richiamare i processori e i gestori Diff, in quanto adesso verranno richiamati automaticamente. Un tipico esempio dell'uso di questo codice, è l'evento Comando per il componente Pulsante di comando. Di seguito è riportato un esempio del codice:
    String Diff = getClientData1().getDiffStr();
    if (DiffProcessor.Synch(getRoot(), Diff) == true)
     return "";
    return "failure";
  3. Rimuovere dal progetto i file corrispondenti ai vecchi gestori personalizzati e processi creati.
Conservare i processori e i gestori Diff scritti per V5.1.x: anche se non consigliato, se si decide di conservare i gestori e i processori diff personalizzati della versione 5.1.x, sarà necessario modificarli affinché possano funzionare nella versione 6.0, in quanto l'interfaccia DiffHandler e la classe DiffInfo sono state modificate.
  • L'interfaccia DiffHandler è stata modificata come segue:
    • Il metodo handle adesso attiva una Exception oltre a una DiffException.
    • Il nuovo metodo find viene utilizzato dal framework per trovare oggetti.
    • Il nuovo metodo getId viene utilizzato per il debug e consente al framework di stampare il valore dell'oggetto.

    I metodi find e getId vengono utilizzati internamente dai DiffHandlers generati. Per i DiffHandler personalizzati, è possibile implementare metodi vuoti solo per compatibilità con l'interfaccia. Questi metodi non verranno richiamati dal framework.

    Adesso l'interfaccia DiffHandler è:
    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 classe DiffInfo è stata modificata come segue:
    • Il metodo ArrayList getAncestors() è stato sostituito dal metodo DiffInfo getParent(), che fornisce un modo più semplice di accedere alle informazioni per ciascun oggetto nella struttura di elementi precedenti in modo ricorsivo.
    • I metodi getCurrent() e getOriginal() adesso restituiscono un oggetto DataObject invece di un oggetto EObject. Non è obbligatorio modificare il codice per utilizzare l'oggetto DataObject. Tuttavia, l'interfaccia DataObject è molto più semplice e più intuitiva da utilizzare rispetto a EObject. È possibile unire facilmente un oggetto DataObject in un oggetto EObject per il codice legacy.
    • È stata aggiunta una nuova stringa di metodo getPropertyName() per identificare il nome della proprietà alla quale viene applicato questo oggetto È importante se, ad esempio, una classe data contiene due proprietà dello stesso tipo. Precedentemente, nella classe DiffInfo, il codice non sarebbe stato in grado di differenziare due proprietà.
    La classe DiffInfo è stata modificata come segue:
    public class DiffInfo
     {
       public char       getCrud()
       public DataObject getCurrent()
       public String     getEClassName()
       public DataObject getOriginal()
       public String     getPropertyName()
       public DiffInfo   getParent()
     }
    Nota: La classe DiffInfo non è più supportata per uso pubblico, in quanto i processori e i gestori Diff non vengono più generati automaticamente. Conservare i vecchi gestori solo come soluzione temporanea e utilizzare i gestori automatici.
Modifiche nei componenti client Faces nella V6.0:
  • Supporto per WebSphere Application Server V6.0.
  • Supporto per SDO (Service Data Objects) su WebSphere Application Server V6.0.
  • Dati EGL supportati come dati client.
  • Gestori e processori Diff generati automaticamente.
  • Nuovi eventi per i seguenti componenti client:
    • TabbedPanel: onInitialPageShow
    • Tree: onNodeExpand, onNodeCollapse, onExpand, onCollapse
    • DataGrid: onPage, onSort, onFilter

Argomento principale: Migrazione da WebSphere Studio V5.1, 5.1.1 o 5.1.2

Attività correlate
Migrazione di risorse JavaServer Faces in un progetto Web
Migrazione di risorse Faces in un progetto portlet

(C) Copyright IBM Corporation 2000, 2004. Tutti i diritti riservati.