Boîte de dialogue Propriétés de l'IDL de VisiBroker

C'est une fonctionnalité de JBuilder Entreprise.

Pour ouvrir la boîte de dialogue Propriétés de l'IDL de VisiBroker, cliquez avec le bouton droit sur un fichier IDL dans le volet projet et sélectionnez Propriétés. Afin que cette boîte de dialogue s'affiche, sélectionnez VisiBroker en tant que compilateur IDL dans la page Construction de Projet|Propriétés du projet.

La boîte de dialogue Propriétés de l'IDL de VisiBroker vous permet de spécifier les options de compilation des interfaces distantes définies en langage IDL (Interface Definition Language). Quand un fichier est compilé, elle génère les définitions d'interfaces Java, les stubs client Java et les squelettes de code serveur. Cela permet à un client Java d'appeler de manière transparente un objet IDL situé sur un serveur distant ou permet à un serveur Java de définir des objets qui peuvent être appelés de manière transparente par des clients IDL.

Quand le compilateur IDL, idl2java, un préprocesseur Java, est appelé en cliquant avec le bouton droit sur un fichier IDL et en sélectionnant Make, le fichier source IDL est compilé, une structure de répertoires contenant l'équivalent en Java des déclarations IDL est créée. Généralement plusieurs fichiers Java correspondent à un seul fichier IDL pour marshaller/dé-marshaller les types de données Java en types CORBA et proposer des messages IIOP. Les noms de fichier IDL doivent se terminer par l'extension .idl. Pour plus d'informations sur ce compilateur, voir VisiBroker for Java Reference.

VisiBroker pour Java est conforme à la OMG IDL/Java Language Mapping Specification.

Traiter ce fichier IDL

Quand cette option est sélectionnée, vous pouvez définir des options de compilation, ajouter au projet en cours les fichiers et/ou paquets compilés et voir les résultats du compilateur.

Quand cette option est cochée, sélectionner OK définit les options à utiliser par l'outil VisiBroker idl2java, un préprocesseur Java, lorsque le fichier IDL est compilé. Définissez les bonnes options pour qu'à la compilation, les définitions des interfaces Java ainsi que les stubs et les squelettes du serveur et du client Java soient générés.

Quand l'option Traiter ce fichier IDL n'est pas cochée, sélectionner OK enregistre les options sélectionnées, mais n'appelle pas le compilateur idl2java lorsque le fichier IDL est compilé. Cela signifie que les stubs client et les squelettes serveur ne sont pas générés lorsque le fichier IDL est compilé.

La première étape de création d'une application de ce type consiste à spécifier tous vos objets et leurs interfaces en utilisant le langage IDL (Interface Definition Language) de OMG. L'IDL peut être mis en correspondance avec de nombreux langages de programmation. La correspondance entre IDL et Java est résumée dans le chapitre "The IDL to Java Mapping" du VisiBroker for Java Reference Manual.

La spécification de l'interface créée est utilisée pour générer les routines stub pour le programme client et le code squelette pour l'implémentation de l'objet. Les routines stub sont utilisées par le programme client pour les invocations de méthodes. Vous utilisez le code squelette, ainsi que le code que vous écrivez, pour créer le serveur qui implémente l'objet. Le code pour le client et celui pour l'objet, une fois terminés, sont utilisées comme entrée de votre compilateur Java pour produire une applet ou une application Java et un serveur d'objet.

Page Options du compilateur

Cette page fournit des options pour modifier le code source Java généré lorsqu'un fichier source IDL est compilé. Par défaut, un préprocesseur Java compile un fichier source IDL et crée une structure de répertoires contenant les correspondances Java des déclarations IDL. Généralement, un fichier IDL sera mis en correspondance avec plusieurs fichiers Java, car Java n'autorise qu'une interface ou classe publique par fichier.

Les options sont traitées avec plus de détails dans le chapitre "Programmer Tools" de la VisiBroker for Java Reference.

Paquet

Du code est généré dans le paquet indiqué. Le nom de paquet pour les définitions est mis au début avec le nom de paquet spécifié. Si un répertoire ayant ce nom de paquet n'existe pas, il sera créé. Si le répertoire paquet existe, son contenu est mis à jour. Lorsque cette option n'est pas définie, idl2java génère du code en utilisant les règles de résolution de paquet CORBA.

Créer un code portable strict

Quand cette option est sélectionnée et que le fichier IDL est compilé, le code qui peut tourner sur n'importe quel ORB conforme à CORBA est généré. Cela signifie que tout code propre au VisiBroker, y compris le code qui génère des stubs, ne sera pas généré. La sélection de cette option supprime également la génération des méthodes toString() et bind().

Si cette option n'est pas sélectionnée, les stubs portables ne sont pas générés. Les extensions et optimisations VisiBroker seront présentes dans le code généré. Les stubs générés seront spécialement destinés à l'utilisation dans des environnements d'ORB VisiBroker.

Lorsque cette option est activée, le compilateur génère le code squelette en utilisant DSI (Dynamic Skeleton Interface). Pour voir comment faire un type quelconque de DSI, créez un fichier IDL, sélectionnez cette option, compilez et regardez le code squelette.

Pour plus d'informations sur cette option, voir le chapitre "The Dynamic Skeleton Interface" du VisiBroker Programmer's Guide.

Créer l'implémentation exemple

Si cette option est sélectionnée, des classes exemple sont générées quand le fichier IDL est compilé. Si elle n'est pas cochée, la génération des classes exemple est supprimée.

Créer les commentaires

Si cette option est sélectionnée, des commentaires sont placés dans le code généré. Si elle n'est pas cochée, les commentaires sont supprimés dans le code généré.

Créer des liaisons "tie"

Si cette option est sélectionnée, des classes _tie sont générées quand le fichier IDL est compilé. Si elle n'est pas cochée, les classes _tie ne sont pas générées.

Le mécanisme Tie (liaisons nouées) offre une classe alternative lorsqu'il n'est pas pratique ou pas possible de dériver la classe d'implémentation de la classe squelette VisiBroker. Les classes d'implémentation d'objets doivent dériver de la classe squelette VisiBroker. Java n'autorise pas l'héritage de classe multiple et vous pouvez vouloir que votre classe d'implémentation dérive d'une autre classe.

L'héritage est plus facile à utiliser que le mécanisme Tie car les objets implémentation se présentent et se comportent comme des références d'objets. S'il arrive qu'un objet implémentation se trouve dans le même processus qu'un client qui l'utilise, les invocations d'opérations prennent moins de temps système, car il n'y a besoin d'aucun transport, indirection, ou délégation d'aucune sorte.

Le mécanisme Tie fournit une classe implémentation de délégateur qui dérive de org.omg.CORBA.Object. La classe implémentation de délégateur ne fournit elle-même aucune sémantique. Elle de contente de déléguer chaque appel vers la classe d'implémentation réelle, qui peut être implémentée séparément et peut donc hériter de n'importe quelle classe.

La classe Operations définit toutes les méthodes qui peuvent être implémentées par l'implémentation de l'objet. Cette classe agit en tant qu'objet délégué pour la classe _tie associée, lorsque le mécanisme Tie est utilisé.

Pour plus d'informations sur cette option, voir le chapitre "The Tie Mechanism" du VisiBroker Programmer's Guide.

Chemin d'inclusion

Cliquez sur le bouton à points de suspension pour ouvrir une boîte de dialogue qui permet de sélectionner le répertoire dans lequel rechercher les fichiers à inclure dans la construction. Vous devez sélectionner un répertoire contenant un fichier .idl.

Options supplémentaires

Ce champ vous permet de spécifier les options qui ne sont pas disponibles dans cette boîte de dialogue. Pour une liste des options possibles, voir la VisiBroker for Java Reference à la section "Programmer Tools : idl2java".

Paramètre IDL2package

Il s'agit de l'équivalent du paramètre en ligne de commande -idl2package idl pkg. Il place les définitions dans la portée de l'idl dans le paquet Java indiqué, par exemple :

-idl2package ::CORBA org.omg.CORBA

Ceci signifie que si une quelconque partie du fichier IDL est dans la portée ::CORBA, son code java généré est placé dans le paquet java org.omg.CORBA.. Dans cet exemple, l'IDL a un nom de module CORBA. Lorsque le code Java est généré, ces classes CORBA doivent avoir le domaine d'appellation org.omg.CORBA. Pour cela, initialisez l'option idl2package de ::CORBA à org.omg.CORBA.

Lorsque cette option n'est pas définie, le compilateur idl2java génère du code en utilisant les règles de résolution de paquet CORBA.

Page Définitions conditionnelles

Symboles définis pour la compilation conditionnelle IDL

Affiche la liste des symboles définies pour la compilation conditionnelle de l'IDL. Cliquez sur Nouveau pour ajouter un nouveau symbole, cliquez sur Supprimer pour enlever le symbole mis en évidence.

Bouton Nouveau

Ouvre une boîte de dialogue qui vous permet de définir un nom de symbole pour la compilation conditionnelle IDL, par exemple #define name def.

Bouton Supprimer

Ce bouton permet de supprimer le symbole sélectionné de la liste des symboles définis pour la compilation conditionnelle.

Bouton OK

Quand l'option Traiter ce fichier IDL est cochée, sélectionner OK définit les options à utiliser par l'outil VisiBroker idl2java, un préprocesseur Java, lorsque le fichier IDL est compilé. Définissez les options correctes afin que, lors de la compilation, les définitions d'interface Java, les stubs client et les squelettes de code serveur soient générés dans un sous-répertoire du projet portant le même nom que le projet.

Quand l'option Traiter ce fichier IDL n'est pas cochée, sélectionner OK enregistre les options sélectionnées, mais n'appelle pas le compilateur idl2java lorsque le fichier IDL est compilé. Cela signifie que les stubs client et les squelettes serveur ne sont pas générés lorsque le fichier IDL est compilé.