Migrazione di codice da VisualAge per Java all'editor visuale

In questo argomento verranno fornite informazioni relative alla migrazione di codice Java da VisualAge per Java.

Quando si apportano modifiche a un componente Java mediante l'editor visuale per Java, il codice di origine viene aggiornato in funzione di tali modifiche. Le modifiche al codice di origine vengono riportate nei metodi set che consentono di modificare i valori delle proprietà. Alcune informazioni utilizzate però dall'editor visuale per Java non vengono memorizzate nelle proprietà perché sono richieste solo in fase di progettazione. Queste informazioni includono la posizione di un bean Java nella superficie di formato libero.

Per memorizzare queste informazioni in modo che l'editor visuale per Java possa essere riaperto con il bean Java nella stessa posizione, esse vengono inserite in un commento nella riga in cui si dichiara il bean Java. Nell'istruzione seguente è illustrato un componente JFrame la cui posizione è 16,17:

private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info
decl-index=0 visual-constraint="16,17"

Non è obbligatorio il commento che rappresenta la posizione di un componente e se non è disponibile alcun commento, verrà assegnata una posizione predefinita all'apertura dell'editor visuale per Java. Questa posizione predefinita si applica solo ai bean di primo livello che non sono contenuti all'interno di un altro bean e non riguarda la posizione dei componenti all'interno di un contenitore. La posizione dei componenti all'interno di un contenitore è determinata dal gestore di layour del contenitore e dalle associazioni o vincoli del componente.

In VisualAge per Java, la posizione dei bean Java di primo livello (noti anche come parti di formato libero) non è presente nel codice di origine. Se si effettua la migrazione di un file scritto con l'editor VCE (Visual Composition Editor) di VisualAge per Java, vengono utilizzate le posizioni predefinite. Se si desidera conservare le informazioni relative alla posizione, è possibile ottenere un'utilità per la migrazione caricata in VisualAge per Java. L'utilità per la migrazione consente di rigenerare le classi con la posizione memorizzata in un formato commento. Per ottenere l'utilità, effettuare il download del più recente strumento di conversione delle applicazioni Visual Composition Editor di VisualAge per Java disponibile nel sito all'indirizzo www.ibm.com/support/us/

Questa utilità è disponibile come correzione temporanea che può essere installata mediante FixManager di VisualAge per Java (da Spazio di lavoro > Strumenti > FixManager). L'utilità consente di migrare ed esportare classi che sono state sviluppate con l'editor VCE di VisualAge per Java in un formato compatibile con l'editor visuale. Una volta installata la patch, è possibile selezionare Generazione/esportazione del codice VCE... dal menu a comparsa di progetti, pacchetti o classi. Selezionando questa opzione viene avviata una procedura guidata in grado di rigenerare il codice delle classi precedentemente salvate con l'editor VCE. Le posizioni in formato libero vengono salvate nel formato commento utilizzato dall'editor visuale.

Se sono disponibili connessioni, è possibile rigenerare questo codice selezionando l'opzione di rigenerazione del codice VCE Utilizza una classe interna per ciascun evento prima di eseguire l'utilità. Alcune classi, tuttavia, non possono essere convertite in questo stile a causa di un problema in VisualAge per Java. In questo caso, è necessario utilizzare l'opzione di generazione del codice VCE Utilizza una classe interna per tutti gli eventi. La procedura guidata inoltre consente di esportare le classi in una directory al completamento della generazione del codice. Il supporto degli eventi dell'editor visuale per Java non analizzerà lo stile di generazione del codice VCE Non utilizzare classi interne.


Modello VCE 1


Modello VCE 2

Poiché l'editor VCE ha conservato il proprio modello di bean Java nonché i relativi valori di proprietà e le relazioni, ha sempre rigenerato il codice di origine dall'alto verso il basso partendo da questo modello. Eventuali modifiche apportate da un utente al codice di origine erano limitate ai punti di codice utente predefiniti nel codice di origine e delimitate dai commenti //user code begin {1} e //user code end. Inoltre, per indicare che i metodi dei bean Java venivano rigenerati ogni volta che veniva eseguita una generazione di codice, veniva aggiunta la riga /* WARNING: THIS METHOD WILL BE REGENERATED. */ al commento del metodo. L'utilità per la migrazione dispone di un'opzione che consente di rimuovere i commenti generati dall'editor VCE dal codice esportato (non dal codice di origine in VisualAge per Java), in quanto non più validi al di fuori dell'editor VCE. Una volta però rimossi i commenti per i punti di codice utente dal codice di origine, il codice utente non può essere utilizzato all'interno di VisualAge per Java. Il motivo è dovuto al fatto che il codice utente non viene sovrascritto grazie alla presenza di questi commenti.

L'editor visuale per Java non utilizza un modello a oggetti persistente per i propri bean Java e per i rispettivi valori di proprietà e le relazioni, piuttosto analizza ogni volta il codice di origine. Per questo motivo, i commenti per i punti di codice utente e per l'indicazione della rigenerazione del metodo non sono più applicabili e le modifiche possono essere apportate liberamente al codice di origine. Se le modifiche alterano la struttura del codice di origine al punto che l'editor visuale per Java non è più in grado di riconoscere la struttura dei bean Java, è possibile che non siano visibili nella vista Progettazione o nella vista Bean Java. Tuttavia, il codice di origine non verrà modificato per adattare lo stile dell'editor e le modifiche verranno conservate.

Argomento principale: Modifica di Java nell'editor visuale

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