Cette rubrique fournit des informations sur la migration du code Java à partir de VisualAge for Java.
Lorsque vous apportez des modifications à un bean Java à l'aide de Visual Editor for Java, le code source est mis à jour pour prendre en compte les modifications. Les modifications apportées au code source sont prises en compte dans les méthodes set qui modifient les valeurs des propriétés. Toutefois, certaines informations utilisées par l'éditeur visuel ne sont pas stockées dans les propriétés car elles sont utilisées uniquement lors de la phase de conception. Ces informations comprennent la position d'un bean Java sur la surface de format libre.
Pour stocker ces informations et rouvrir l'éditeur visuel en conservant le bean Java au même emplacement, vous devez les placer dans un commentaire sur la ligne qui déclare le bean Java. L'instruction suivante affiche un composant JFrame positionné à l'emplacement 16,17:au même emplacement, vous devez les placer dans un commentaire sur la ligne qui déclare le bean Java.
private javax.swing.JFrame ivjJFrame = null; // @jve:visual-info decl-index=0 visual-constraint="16,17"
La définition d'un commentaire représentant la position d'un composant n'est pas nécessaire. S'il n'y a pas de commentaire, le programme affecte une position par défaut lors de l'ouverture de Visual Editor for Java. Ce positionnement par défaut s'applique uniquement aux beans Java de niveau supérieur qui ne sont pas stockés dans un autre bean et n'affecte pas le positionnement des composants au sein d'un conteneur. L'emplacement des composants au sein d'un conteneur est déterminé par le gestionnaire de présentation du conteneur et par les limites ou les contraintes du composant.
Dans VisualAge for Java, la position des beans Java de niveau supérieur (également appelés éléments de format libre) n'est pas indiquée dans le code source. Si vous migrez un fichier écrit avec l'éditeur de composition visuelle de VisualAge for Java, les positions par défaut sont utilisées. Si vous souhaitez conserver les informations de positionnement, vous pouvez faire appel à un utililitaire de migration chargé dans dans VisualAge for Java. L'utilitaire de migration permet de régénérer les classes avec la position stockée sous la forme d'un commentaire. Pour vous procurer l'utilitaire, téléchargez la dernière version de l'outil de conversion pour les applications de l'éditeur de composition visuel VisualAge for Java sur le site www.ibm.com/support/us/
Cet utilitaire de migration est disponible sous la forme d'un correctif provisoire que vous pouvez installer à l'aide du composant Fix Manager de VisualAge for Java (Espace de travail > Outils > Fix Manager). L'utilitaire permet de migrer et d'exporter des classes développées à l'aide de l'éditeur de composition visuelle de VisualAge for Java dans un format reconnu par l'éditeur visuel. Après avoir installé ce module correctif, vous pouvez sélectionner Exportation/Génération du code VCE... dans le menu en incrustation des projets, des packages ou des classes. La sélection de cet élément lance un assistant qui peut régénérer le code des classes précédemment sauvegardées avec l'éditeur de composition visuelle. Les positions de format libre sont sauvegardées sous la forme de commentaires utilisés par l'éditeur visuel.
Si vous disposez de connexions, vous pouvez d'abord regénérer ce code en sélectionnant l'option de génération du code VCE Utiliser une classe interne pour chaque événement avant d'exécuter cet utilitaire. Toutefois, certaines classes ne pourront pas être converties dans ce style en raison d'un bogue de VisualAge for Java. Dans ce cas, vous devez utiliser l'option de génération du code VCE Utiliser une classe interne pour tous les événements. L'assistant vous permet également d'exporter les classes dans un répertoire à l'issue de la génération du code. Le support d'événements de Visual editor for Java n'effectue pas l'analyse syntaxique le style de génération du code VCE Ne pas utiliser les classes internes.
Comme l'éditeur de composition visuelle gère son propre modèle de beans Java, les valeurs de propriétés et les relations associées, il régénère toujours le code source de manière descendante à partir de ce modèle. Toutes les modifications qu'un utilisateur peut apporter au code source sont limitées à des sections de code prédéfinies et délimitées par les commentaires //user code begin {1} et //user code end. Pour indiquer que les méthodes des beans Java ont été régénérées chaque fois qu'une génération de code est effectuée, la ligne /* WARNING: THIS METHOD WILL BE REGENERATED. */ est ajoutée au commentaire de la méthode. L'utilitaire de migration permet de supprimer les commentaires générés par l'éditeur de composition visuelle du code exporté (pas du code source de VisualAge for Java) car ils ne sont pas utilisés hors de l'éditeur de composition visuelle. Toutefois, une fois que les commentaires associés au code de l'utilisateur sont supprimés du code source, le code de l'utilisateur ne peut plus être utilisé dans VisualAge for Java. En effet, la présence de ces commentaires empêche la suppression du code de l'utilisateur.
Visual Editor for Java n'utilise pas de modèle d'objet persistant pour ses beans Java, les valeurs des propriétés et les relations associées ; à la place, il effectue une analyse syntaxique du code source. Pour cette raison, les commentaires des points de code et de régénération de la méthode ne s'appliquent plus et les modifications peuvent être apportées librement au code source. Si les modifications ont une incidence telle sur la structure du code source que Visual Editor for Java ne peut plus reconnaître la structure des beans Java, il est possible qu'ils ne s'affichent plus dans la vue Conception ou la vue Beans Java. Toutefois, le source ne sera pas modifié en fonction du style de l'éditeur et les modifications seront conservées.
Rubrique parent : Edition de Java dans l'éditeur visuel