Dieser Abschnitt enthält Informationen über die Migration eines Java-Codes aus VisualAge für Java.
Wenn Sie unter Verwendung des Visual Editors für Java Änderungen an einer Java-Komponente vornehmen, wird der Quellcode aktualisiert, um diese Änderungen widerzuspiegeln. Die Änderungen des Quellcodes werden in 'set'-Methoden widergespiegelt, die die Eigenschaftswerte ändern. Einige Informationen jedoch, die durch den Visual Editor für Java verwendet werden, werden nicht in den Eigenschaften gespeichert, da sie nur zur Entwurfszeit benötigt werden. Diese Information beinhaltet die Position einer Java-Bean auf der unformatierten Oberfläche.
Um diese Informationen zu speichern, damit der Visual Editor für Java wieder mit der Java-Bean an derselben Position geöffnet werden kann, wird sie in einen Kommentar für die Zeile gestellt, die die Java-Bean deklariert. Die folgende Anweisung zeigt eine JFrame-Komponente, die an 16,17 positioniert ist:
private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info decl-index=0 visual-constraint="16,17"
Der Kommentar, der die Position einer Komponente darstellt, ist nicht erforderlich, und wenn kein Kommentar vorhanden ist, wird eine Standardposition zugeordnet, wenn der Visual Editor für Java geöffnet wird. Diese standardmäßige Platzierung trifft nur auf Java-Beans der höchsten Ebene zu, die nicht in einer anderen enthalten sind und die die Platzierung von Komponenten innerhalb eines Containers nicht beeinflussen. Die Position von Komponenten innerhalb eines Containers wird durch den Layout-Manager des Containers und durch die Begrenzungen oder Integritätsbedingungen der Komponente festgelegt.
In VisualAge für Java ist die Position der Java-Beans der höchsten Ebene (auch als unformatierte Teile bezeichnet), nicht im Quellcode enthalten. Wenn Sie also eine Datei migrieren, die unter Verwendung von VisualAge für Javas Visual Composition Editor (VCE) geschrieben wurde, werden Standardpositionen verwendet. Wenn Sie die Positionsinformationen beibehalten möchten, können Sie ein Migrationsdienstprogramm erhalten, das in VisualAge für Java geladen wird. Dieses Migrationsdienstprogramm regeneriert Ihre Klassen mit der in einem Kommentarformat gespeicherten Position. Um dieses Dienstprogramm zu erhalten, downloaden Sie die neueste Version des Conversion tool for VisualAge for Java Visual Composition Editor applications unter www.ibm.com/support/us/
Dieses Migrationsdienstprogramm steht als Tempfix zur Verfügung, das unter Verwendung von VisualAge for Javas FixManager (über Arbeitsbereich > Tools > FixManager)installiert werden kann. Dieses Dienstprogramm ermöglicht Ihnen, Klassen, die unter Verwendung von VisualAge für Javas VCE entwickelt wurden, in einem für den Visual Editor geeigneten Format zu migrieren und zu exportieren. Nach der Installation dieses Patches können Sie ein Menüelement namens 'VCE Code generieren/exportieren...' aus dem Kontextmenü der Projekte, Pakete oder Klassen auswählen. Durch die Auswahl dieses Elements wird ein Assistent gestartet, der Ihnen ermöglicht, den Code für Klassen, die zuvor mit VCE gespeichert wurden, neu zu generieren. Die unformatierten Positionen werden in dem Kommentarformat gespeichert, das durch den Visual Editor verwendet wird.
Wenn Sie die Verbindungen haben, können Sie zuerst diesen Code neu generieren, indem Sie VCE-Codegenerierungsoption Eine untergeordnete Klasse für jedes Ereignis verwenden auswählen, bevor Sie dieses Dienstprogramm ausführen. Aufgrund eines Programmfehlers in VisualAge für Java lassen sich jedoch einige Klassen nicht in diese Darstellung konvertieren. In diesem Fall sollten Sie die VCE-Codegenerierungsoption Eine untergeordnete Klasse für alle Ereignisse verwenden verwenden. Der Assistent bietet Ihnen auch die Option, die Klassen in ein Verzeichnis zu exportieren, wenn die Codegenerierung abgeschlossen ist. Die Ereignisunterstützung des Visual Editors wird die VCE Codegenerierungsdarstellung Keine untergeordneten Klassen verwenden nicht syntaktisch analysieren.
Das VCE das eigene Modell der Java-Beans und deren Eigenschaftswerte und Beziehungen beibehält, wird immer die Quelle in einer Top-down-Art von diesem Modell neu generiert. Alle durch den Benutzer an der Quelle vorgenommenen Änderungen waren beschränkt auf vordefinierte Benutzercodepunkte in der Quelle, die durch die Kommentare //user code begin {1} und //user code end. begrenzt wurden. Weiterhin wurde, um anzuzeigen, dass die Methoden für die Java-Beans jedesmal dann neu generiert werden, wenn eine Codegenerierung durchgeführt wird, die Zeile /* ACHTUNG: DIESE METHODE WIRD NEU GENERIERT. */ dem Methodenkommentar hinzugefügt. Das Migrationsdienstprogramm verfügt über eine Option, die diese VCE-generierten Kommentare aus dem exportierten Code (nicht aus dem Quellcode in VisualAge für Java) löscht, da sie außerhalb der VCE nicht länger anwendbar sind. Wenn jedoch die Kommentare für die Benutzercodepunkte einmal aus der Quelle gelöscht worden sind, kann der Code nicht mehr in VisualAge für Java verwendet werden. Der Grund dafür ist, dass es das Vorhandensein dieser Kommentare ist, was den Benutzercode davor schützt, überschrieben zu werden.
Der Visual Editor für Java verwendet kein permanentes Objektmodell für seine Java-Beans und deren Eigenschaftswerte und Beziehungen, sondern analysiert die Quelle jedesmal syntaktisch. Aus diesem Grund treffen die Kommentare für Benutzercodepunkt und für die Angabe der Neugenerierung der Methode nicht länger zu und beliebige Änderungen am Quellcode können vorgenommen werden. Wenn die Änderungen die Struktur des Quellcodes so verändern, dass der Visual Editor für Java die Struktur der Java-Beans nicht mehr erkennen kann, können Sie diese eventuell nicht in der Entwurfsansicht oder der Java-Beans-Sicht sehen. Jedoch wird die Quelle nicht so geändert, dass sie der Darstellung des Editors angepasst wird, und die von Ihnen vorgenommenen Änderungen bleiben erhalten.
Übergeordnetes Thema: Java im Visual Editor bearbeiten