Evaluation du couplage entre Designer & JDeveloper d Oracle

Transcription

1 Travail de diplôme d informaticienne de gestion HES Evaluation du couplage entre Designer & JDeveloper d Oracle Cahier pratique Etudiante Astrid von Wyl Directeur du travail Pierre-André Sunier Date de restitution Février 2005 Cycle d études Plein temps

2 Table des matières 1. Introduction Outil Espace de travail Créer un projet Connexion Diagramme Propriétés d une entité Name Attributs Contraintes Séquences Autres nœuds de la fenêtre des propriétés d une entité Associations Vues Composants modules Couche modèle Génération d applications à partir de nos propres spécifications Importation d un module depuis Oracle Designer Perte /conservation d information lors de l importation Génération d applications à partir de modules Designer avec scripts d APIS et SQL-DDL Module avec table de référence Module avec LOV Module maître-détail avec entité associative Module avec champs calculés Lien réflexif Synthèse de l importation Clé primaire Champs d audit et domaines Validation Vues et modules Navigation Enrichissement du module et synchronisation Couche view/controller ADF UIX LOV Types JSP LOV Types Java Client LOV sur 73 Astrid von Wyl

3 4.4. JHeadstart LOV JSP JSP avec LOV Types Personnalisation des applications Remarques Affichage d un module avec table de référence Web Client Java Client Application garage Importation Affichage, couche vue Champs calculés ADFUIX Erreur JSP Java Client JHeadstart Evaluation du couplage Conclusion Annexes Figures Options du fichiers ApplicationStructure.xml Remerciements sur 73 Astrid von Wyl

4 1. Introduction Le but de cette partie pratique est de montrer une partie des possibilités d utilisations de JDeveloper. L outil est d abord utilisé seul, puis en couplage avec Designer. Les tests se font autant pour la couche modèle que pour la couche vue des applications. Dans tout le travail, je pars du principe qu Oracle Designer est connu du lecteur. Ma démarche est la suivante, tout d abord, j ai commencé par me familiariser avec l outil en suivant les cahiers 1 à 3 du cours d AGL 1. Ces cahiers traitent des points suivants : de la structure du référentiel, de la modélisation conceptuelle de données, du passage du niveau conceptuel au niveau logique, de la modélisation logique de données, de la génération des scripts SQL-DDL, de la génération des APIs de table, du modèle de traitement, de la génération des procédures PL/SQL de création de pages HTML dynamiques, de l utilisation des modules de traitement via IAS, des mécanismes de notification, des types de données, des clés secondaire, des associations, des champs d audit, des journaux de table, du mécanisme de consolidation de bases de données, des propriétés d affichage, des tables de références, des listes de valeurs de référence, des cardinalités des associations, des attributs des associations 1 :1 et 1 :N, des contraintes, des formulaires maître-détails, des associations non transférables, des associations identifiantes, des contraintes d intégrité référentielles, des contraintes d unicité d association, des champs calculés Dans le chapitre outil, j étudie ces notions au fur et à mesure de ma progression dans la compréhension de l outil. JDeveloper repose sur le modèle MVC (modèle-vue-contrôleur). C est pourquoi la suite du cahier est décomposé en deux parties : vue et modèle. Le deuxième chapitre est consacré à la couche modèle d une application. Pour travailler dans cette couche, je réalise deux connexions, la première à une base de données et la seconde à une instance de l AGL Designer. J utilise JDeveloper pour spécifier les entités d une application, puis je génère le modèle de base de données associé. Je fais ensuite des essais avec Designer. J importe un module Clients-Representants depuis Designer pour étudier la manière dont JDeveloper traite ces informations. Les «applications» de cette couche sont ensuite testées. Le troisième chapitre est consacré à la couche vue du modèle MVC. Pour tester cette couche, je reprends trois modules de Designer : un module Clients, un module Clients- Représentants (table de référence), un module Clients-représentants (avec LOV). 1 Voir le site sur 73 Astrid von Wyl

5 Pour chacun de ces modules, je vais expérimenter les trois manières de procéder possibles. La couche vue peut être soit un client java, soit un client web. Ce dernier peut être réalisé à l aide de deux technologies : ADF UIX et JSP. Suite à mes recherches, je réalise également une application complète avec JHeadstart. La quatrième chapitre est consacré à une application développée avec Designer. Il s agit d une application de gestion des réparations dans un garage. Le but du quatrième chapitre est de générer l application avec les trois possibilités de la couche vue et JHeadstart qui est une extension de JDeveloper. J ai choisi ce sujet, car j estime qu il contient un bon équilibre entre théorie et pratique. De plus j ai l impression que la partie théorique peut être vérifiée par la pratique. J ai une préférences pour les sujets qui touchent un domaine inconnu sur 73 Astrid von Wyl

6 2. Outil Pour pouvoir utiliser l outil JDeveloper, il faut définir un espace de travail, un projet et une connexion à une base de données Espace de travail Pour créer l espace de travail, il faut choisir dans le navigateur l onglet Applications(Figure 1) et avec un click-droit sur la racine de l arborescence Applications dérouler le menu (Figure 2). Figure 1 Figure 2 Sélectionner New Application Workspace. L assistant de création d espace de travail est déployé (Figure 3). Figure 3 Pour pouvoir profiter d ADF BC, les modèles d application à utiliser sont : Java Application [Default] : Génère un projet ADFJclient et un projet ADF BC. Web Application [Default] : Génère un projet pour la couche vue + contrôleur et un autre pour la couche modèle. Web Application [Default, no controller] : Génère un projet pour la couche vue et un autre pour la couche modèle, pas de contrôleur sur 73 Astrid von Wyl

7 2.2. Créer un projet Dans l arborescence du navigateur de l onglet Application, dérouler le menu sur l application choisie et cliquer sur >New. Ensuite, sélectionner le type de projet que l on souhaite créer (Figure 4). Figure 4 Pour chaque projet il est possible d éditer des propriétés. A cet effet, choisir le menu Tools> Project properties. Parmi les propriétés, il y a la définition d une connexion à une base de données, le choix des technologies qu il est possible d utiliser dans le projet, p.ex. EJB, Struts, UML. D autres propriétés définissent les classes java qui seront créées, les chemins etc.. La définition du projet est contenue dans un fichier à l extension.jpx (Figure 5). Ce fichier est visible depuis l onglet system. <?XML version='1.0' encoding='windows-1252'?> <!DOCTYPE JboProject SYSTEM "jbo_03_01.dtd"> <JboProject Name="Project" SeparateXMLFiles="true" PackageName="" > <DesignTime> <Attr Name="_version" Value=" " /> <Attr Name="_jprName" Value="../Project.jpr" /> <Attr Name="_ejbPackage" Value="false" /> <Attr Name="_NamedConnection" Value="ConnexionG04" /> </DesignTime> <Containee Name="mypackage" FullName="mypackage.mypackage" ObjectType="JboPackage" > </Containee> </JboProject> 2.3. Connexion Figure 5 Pour établir la connexion à une base de données avec Oracle JDeveloper 10g, dans le navigateur, choisir l onglet connections (Figure 6) et développer dans l arborescence le nœud Database (Figure 7). Figure sur 73 Astrid von Wyl

8 Figure 7 Dérouler le menu avec click-droit sur le type de connexion voulu > New Database connection. L assistant de création de connexion apparaît, il faut alors saisir les paramètres JDBC suivants : Connection Name : ConnectionG02 Connection type : Oracle(JDBC) JDBC-ODBC Bridge Oracle Lite Third Party JDBC Drive Username: DIPL04AVW_G02 Password:******* Role: - Driver: thin Host Name: leto.cpln.ch JDBC Port: 1521 SID: es28 Figure 8 La dernière étape de l assistant offre la possibilité de tester la connexion et de corriger d éventuelles erreurs. L arborescence du nœud Database (Figure 7) s agrandit, un nœud pour chaque type d objet de la base de donnée est crée (Figure 9). Figure 9 Les objets contenus dans la base de données peuvent être visualisés en déroulant le nœud correspondant dans l arborescence. La connexion est visible dans la fenêtre de structure (Figure 10). Figure 10 Les données liées à la connexion se trouvent dans le fichier bc4j.xcfg. Il contient notamment les paramètres JDBC, le nom des modules, leur portée. Ce fichier est visible depuis l onglet system sur 73 Astrid von Wyl

9 <?XML version = '1.0' encoding = 'UTF-8'?> <BC4JConfig> <AppModuleConfigBag> <AppModuleConfig name="clientsappmodulelocal"> <AppModuleJndiName>ClientsPackage.ClientsAppModule</AppModuleJndiName> <DeployPlatform>LOCAL</DeployPlatform> <JDBCName>ConnexionG04</JDBCName> <ApplicationName>ClientsPackage.ClientsAppModule</ApplicationName> <jbo.project>clients</jbo.project> </AppModuleConfig> </AppModuleConfigBag> <ConnectionDefinition name="connexiong04"> <ENTRY name="jdbc_port" value="1521"/> <ENTRY name="connectiontype" value="jdbc"/> <ENTRY name="hostname" value="leto.cpln.ch"/> <ENTRY name="user" value="dipl04avw_g04"/> <ENTRY name="connectionname" value="connexiong04"/> <ENTRY name="sid" value="es28"/> <ENTRY name="jdbcdriver" value="oracle.jdbc.driver.oracledriver"/> <ENTRY name="password"> <![CDATA[{904}0516E666252DCC0C13E894B6904A2696C]]> </ENTRY> <ENTRY name="oracle_jdbc_type" value="thin"/> <ENTRY name="deploypassword" value="true"/> </ConnectionDefinition> </BC4JConfig> 2.4. Diagramme Figure 11 Dans Oracle JDeveloper 10g, à l aide du business components diagram, il est possible de spécifier ou de représenter des entités. Pour créer ce diagramme, cliquer sur le projet NEW> General >Diagrams (Figure 12). Figure 12 Les objets que l on peut mettre dans ce diagramme sont proposés par la palette des composants (Figure 13) sur 73 Astrid von Wyl

10 Figure 13 Une entité spécifiée avec ce diagramme se présente de telle façon (Figure 14): Figure 14 Figure 15 La fenêtre de structure (Figure 15) montre la structure de l entité. A partir du diagramme, il est possible de procéder à deux générations : sur 73 Astrid von Wyl

11 Default Data Model Components : Génère le composant module correspondant aux spécifications des entités ainsi que des vues et les liens vues. Database objects : Génère la table correspondant aux spécifications dans un schéma de base de données Propriétés d une entité Pour une entité, on peut définir des attributs. Ces attributs ont un type en tant qu attribut d une entité et en tant que colonne dans une table. Il y a neuf nœuds dans la fenêtre des propriétés d un attribut : Name, Attributes, Tuning, Java, Validation, Publish, Suscribe, Authorization, Custom properties. Je les décris un à un ci-dessous Name Si l entité est la définition d une table déjà existante, choisir la connexion à un schéma et la table à laquelle l entité est liée : Attributs Figure 16 Les colonnes qui existent dans la table mais qui ne se trouvent pas sous forme d attribut dans l entité sont générées après que l on ait lié l entité à une table (Figure 16). Selon les besoins, des attributs sont définis dans l entité mais de manière non persistante. Ils n existent pas sous forme de colonne de la table. Pour chaque attribut créé, des propriétés sont définies : sur 73 Astrid von Wyl

12 Figure 17 Persistent : Persistance ou non d un attribut Mandatory : Attribut obligatoire ou non. Si la case est cochée, une contrainte not null est générée. Discriminator : La case est cochée si cet attribut permet de distinguer une entité polymorphe d une autre. En effet, JDeveloper regroupe les objets polymorphes dans une seule classe. Change indicator 2 : Il faut cocher cette case si la colonne est un indicateur de changement, par exemple un timestamp. La plate-forme ADFBC utilise cet indicateur pour déterminer si un tuple a déjà été modifié dans une autre transaction ou peut être verrouillée. S il n y pas de colonne spécifiée comme indicateur de changement, une comparaison colonne par colonne est effectuée. Selected in query : L attribut apparaît dans la requête SQL de la vue. Primary key : Attribut de clé primaire. Si la case est cochée, une contrainte de clé primaire est générée. Unique: Définit si l attribut est unique ou non. Si la case est cochée, une contrainte d unicité est générée. Queriable: Attribut qui apparaît dans les formulaires de recherches. History column: Champ d audit. (created on modified on created by modified by version number). Ne fonctionne pas si l attribut a les propriété suivantes: clé primaire, obligatoire ou discriminant, Updateable : L attribut peut-il être mis à jour? While new s utilise pour les clés primaires par exemple. Always pour un numéro de téléphone par exemple et Never pour un attribut d une table de lookup. Refresh after : Si un trigger existe, cocher la case correspondante au type de trigger. Database column : Définit le nom de la colonne dans la table ainsi que son type. Le fichier Impl.java (Figure 18) dépend directement des ces propriétés. Par exemple Updateable never a pour conséquence qu aucune méthode set () n est écrite pour l attribut. 2 Traduit de l aide en ligne sur 73 Astrid von Wyl

13 Figure 18 L onglet Attribute properties (Figure 19) contient des attributs qui se trouvent dans les méta données. Ces propriétés se trouvent dans le fichier XML associé à l entité. Ci-dessous, les propriétés sont extraites automatiquement lors d une importation d un module depuis Designer. Figure 19 Par défaut, on peut choisir entre quatre noms Description File name XML element XML Explicit null. Un autre nom de propriété peut être défini, par exemple prompt (Figure 19)) Il n y a pas de lien entre ces propriétés et celles définies dans les autres onglets, par exemple display et la propriété display de l onglet décrit ci-dessous. Ces propriétés sont utilisées selon le besoin lors de l exécution. Les propriétés des entités sont liées au fichier XML correspondant à l entité. Celui-ci contient les propriétés décrites ci-dessus. En voici un extrait : sur 73 Astrid von Wyl

14 <Attribute Name="Nom" IsNotNull="true" Precision="255" ColumnName="NOM" Type="java.lang.String" ColumnType="VARCHAR2" SQLType="VARCHAR" TableName="MON_CLIENT" > <Data> <Property Name ="ID" Value ="901fd ::mypackage1.EntityObject1::EntityObjectAttribute" /> <Property Name ="CHANGEABILITY" Value ="CHANGEABLE" /> <Property Name ="OWNER_SCOPE" Value ="INSTANCE" /> <Property Name ="MULTIPLICITY" Value ="1" /> <Property Name ="VISIBILITY" Value ="PACKAGE" /> </Data> </Attribute> Figure 20 L onglet control hints permet de définir des paramètres d affichage pour l attribut : Figure 21 Display hint : Display hide affiche ou non l attribut. Label text : Etiquette qui correspond à l attribut. Tooltip text : Texte qui sera contenu dans l information relative à l attribut. Format type : Par exemple Date. Format : Selon le type de l attribut, différents formats sont proposés, par exemple (yyyy-mm-dd) si Format type = Date. Control type : Date Edit Default. Date affiche un calendrier, edit rend le contrôle de champ éditable et default le client choisit le plus approprié. Display width : Largeur du champ. Display height: Hauteur du champ. Form Type : Détermine le type d affichage: Detail summary. Le type detail aligne tous les attributs dans une colonne Summary les affiche sous forme de grille. Cette propriété n est valable que pour les couches vues de types Jclient. Lorsque l on saisit des valeurs dans l onglet control hints, un fichier ImplMsgBundle.java est créé pour l entité (Figure 22). Ce fichier correspond au contenu de l onglet control hints sur 73 Astrid von Wyl

15 package mypackage1.common; import oracle.jbo.common.jboresourcebundle; public class MonClientImplMsgBundle extends JboResourceBundle { public MonClientImplMsgBundle() { } public Object[][] getcontents() { return super.getmergedarray(smessagestrings, super.getcontents()); } static final Object[][] smessagestrings = { {"Nom_LABEL", "Nom du client"}, {"Nom_DISPLAYWIDTH", "50"}}; } Contraintes Figure 22 Les contraintes sont générées à partir des propriétés définies pour les attributs. Elles sont définies dans le fichier XML correspondant à l entité (Figure 23). <Key Name="MonClientNumeroCheck" > <AttrArray Name="Attributes"> <Item Value="mypackage1.MonClient.Numero" /> </AttrArray> <DesignTime> <Attr Name="_DBObjectName" Value="MON_CLIENT_NUMERO_CHECK" /> <Attr Name="_checkCondition" Value=""NUMERO" IS NOT NULL" /> <Attr Name="_isNotNull" Value="true" /> <Attr Name="_isCheck" Value="true" /> </DesignTime> </Key> <Key Name="MonclientPrimaryKey" > <AttrArray Name="Attributes"> <Item Value="mypackage1.MonClient.Numero" /> </AttrArray> <DesignTime> <Attr Name="_DBObjectName" Value="MONCLIENT_PRIMARY_KEY" /> <Attr Name="_isPrimary" Value="true" /> </DesignTime> </Key> Figure 23 Contrainte not null : Il faut cocher la case mandatory dans les propriétés de l attribut. Cette contrainte permet d éviter que Oracle JDeveloper 10g interroge la Base de données mais vérifie lui-même la validité d un champ. Contrainte de clé primaire : La case à cocher primary key dans les propriétés de l attribut permet de spécifier la clé primaire. Si une table n a pas de clé primaire qui est spécifiée, Oracle JDeveloper 10g crée une clé primaire basée sur la pseudo-colonne ROWID. Contrainte d unicité : La case à cocher unique génère une contrainte d unicité. Contrainte de check : Définir une nouvelle contrainte (Figure 24). Par défaut JDeveloper crée des contraintes de type check pour les contraintes not null. Une contrainte peut être créée à partir d une entité ou par click-droit sur l entité <New Entity Constraint sur 73 Astrid von Wyl

16 Figure 24 Mandatory : La colonne est obligatoire. Deferrable validation : La vérification de la contrainte peut être effectuée à la fin de la transaction. Disable validation : Désactive la contrainte, efface les indexes et interdit toute modification de la colonne concernée par la contrainte. Toute nouvelle colonne ou colonne modifiée peut violer la contrainte. Enable validation, validate existing data : La contrainte est vérifiée et doit être respectée pour toutes les nouvelles données et pour les données existantes. Enable validation : Les anciennes valeurs ne sont pas vérifiées, seules les nouvelles insertions sont contrôlées. Les contraintes sont visibles dans la fenêtre de structure (Figure 25). Figure 25 Remarque : La clé secondaire que l on trouve dans Designer doit être spécifiée comme une contrainte d unicité Séquences Il existe un type DBSequence pour définir la clé primaire dans les propriétés de l entité. Le fait de choisir DBSequence comme type met automatiquement updateable à while new, met en grisé refresh after insert, coche la case queriable et ajoute un onglet sequence à côté de database column. L onglet séquence permet de définir un nom pour la séquence dans le schéma de base de données (Figure 26). Figure sur 73 Astrid von Wyl

17 Autres nœuds de la fenêtre des propriétés d une entité Tuning: Permet de définir le nombre d enregistrements modifiés qui seront envoyés en même temps à la base de données. Ne fonctionne pas si refresh on update or insert est coché. Java: Définition des classes java qui seront générées pour l entité. Validation : Le nœud validation permet de définir des règles des validation, par exemple, la valeur d un attribut doit être plus grande que 10 ou comprise entre 60 et 900. Un message d erreur personnalisé peut être rédigé afin de savoir quelle règle a été violée. Ces règles de validation permettent de réaliser la validation dans l application et évitent ainsi un trafic réseau inutile. Publish: Crée un événement lié à l entité. Suscribe: Choix des événements auxquels l entité va réagir. Authorization: Gestion des droits d accès à l entité ou à un ou plusieurs de ses attributs. Custom properties: Permet d ajouter des descriptions dans les méta données Associations Une association entre deux entités peut être dessinée sur le diagramme de type business components diagram. Elle y est représentée par : ou l une des variantes de multiplicité. Une autre façon de définir une association est de cliquer sur New>Association sur l entité ou le package. Les propriétés de l association sont : (Figure 27) Figure 27 Sur la Figure 27, on définit la source et la destination de l association. Les associations sont orientées par défaut dans les deux sens. C est à dire que pour les deux extrémités de l association une instance de l entité source peut accéder à une instance de l entité destination. Pour enlever cette orientation, il faut enlever les accesseurs. On accède aux définitions des accesseurs par le nœud association properties (Figure 28) sur 73 Astrid von Wyl

18 Figure 28 Expose Accessor : Autorise l accès à l entité source via cet accesseur Use Database Key Constraints: Création de contraintes de niveau entité. La contrainte de clé étrangère va être créée afin de représenter l association. Le fait de décocher cette case n efface pas les contraintes déjà générées. Composition Association: Créer une composition. Dans une composition la destination fait logiquement partie de la source. Optimize for Database Cascade Delete: Empêche la base de données de générer du code DML qui efface chaque tuple de destination. Implement cascade DELETE : Implémente DELETE cascade dans le middle-tier Cascade Update Key Attributes: Les attributs de la destination changent si la source change. Lock Top-level Container: Verrouille la source lorsque la destination est verrouillée. Update Top-Level History Columns: Met à jour les champs d audit de la source lorsque la destination est modifiée. Si un accesseur existe seulement dans la source, l association est unidirectionnelle et ne peut être traversée que de la source à la destination. Dans notre cas, si l accesseur existe sur Representants uniquement, cela signifie que des enregistrements de la destination, en l occurrence Clients sont retournés. Figure 29 Le fichier XML correspondant à l association contient la propriété suivante pour la destination de l association, en l occurrence Clients. ExposedAccessor="false" Aucun accesseur n est disponible pour une instance de l entité Clients. Par contre une instance de l entité représentants accède à des instances de l entité Clients. Le sens de la flèche montre cette situation sur 73 Astrid von Wyl

19 Figure 30 La manière de spécifier les associations influence la navigation dans les composants modules Vues Une vue est une représentation d une table ou vue de la base de données. Mais elle possède des informations supplémentaires à celles contenues dans la base de données, par exemple des champs calculés. La vue contient la requête de type SELECT qui est exécutée sur le schéma de base de données. Une vue peut se référer à plusieurs entités. Les vues n ont pas les mêmes propriétés que les entités. Les attributs d une vue se composent des nœud suivants (Figure 31 ): Figure 31 Entity objects : Ce nœud permet de définir quelles entités composent la vue. Attributes : Montre les attributs disponibles et ceux qui sont sélectionnés. Les attributs sélectionnés feront partie de la requête. Dès lors, les champs d audit sont de trop. Ils n ont pas besoin d apparaître dans le formulaire de test de module. Les attributs numero qui font partie d une relation sont obligatoires. Query : La requête représentée est un select des attributs sélectionnés dans la vue. Il est possible de personnaliser la requête en cochant la case expert mode. Mais dès lors «un retour en arrière implique la perte d informations». 3 La requête peut contenir une clause where et définir un order by. 3 Extrait de l Aide en ligne sur 73 Astrid von Wyl

20 SELECT LReprEntityUsage.NOM, LReprEntityUsage.PRENOM, LReprEntityUsage.MNEMO, ClientsEntityUsage.NUMERO, ClientsEntityUsage.REPR_NUMERO, ClientsEntityUsage.NOM AS NOM1, ClientsEntityUsage.PRENOM AS PRENOM1, ClientsEntityUsage.RUENO, ClientsEntityUsage.CODEPOSTAL, ClientsEntityUsage.LOCALITE, LReprEntityUsage.NUMERO AS NUMERO1 FROM CLIENTS ClientsEntityUsage, REPRESENTANTS LReprEntityUsage WHERE (ClientsEntityUsage.REPR_NUMERO = LReprEntityUsage.NUMERO) Figure 32 Attribute mapping (Figure 33) : On établit le lien entre les colonnes de la table de la base de données et les attributs de la vue. Pour pouvoir éditer ces propriétés, il faut cocher la case expert mode dans le nœud query. A partir de là, on peut personnaliser en cas de besoin, la relation entre les colonnes des tables et les attributs des vues. Une colonne de la table (si elle n est pas obligatoire) peut n être liée à aucun attribut. Figure 33 Tuning (Figure 34): Offre la possibilité de définir la façon dont les données sont extraites de la base de données. Figure 34 «1. As Needed: Le resultset demeure ouvert et les tuples sont retrouvés au fur et à mesure que l utilisateur navigue. Lorsque la fin du resultset est atteinte, celui-ci est fermé. 2. All at Once: Tous les tuples sont retrouvés même si l utilisateur ne navigue pas. Une fois que tous les tuples ont été retrouvés le resultset est fermé. Utile si le nombre de tuples est faible. 3. Page-by-Page Iteration Mode: Si on souhaite éviter la répétition des données Allow Partial Last Page, sinon (Keep Last Page Full )la dernière page est remplie avec des risques de doublons sur 73 Astrid von Wyl

21 4. Fetch Size : Indique le nombre de tuples que l on souhaite capturer à la fois lorsque As needed est sélectionné. 5. Maximum Fetch Size : Définit le nombre maximal de tuples à capturer. 6. Query Hint : Permet d optimiser ou non une requête. 7. Enable Passivation: Si la case est décochée, les modifications sur des attributs persistants ou dérivés seront enregistrées mais le cache de la vue sera vide et la requête devra être exécutée à nouveau si on veut voir les nouvelles données. 8. For all Transient Attibutes: Les modifications des attributs transients sont écrit en cache.» 4 Java (Figure 35): Définition des classes java générées. Par défaut seule une classe est générée pour la vue, mais une classe peut aussi être générée pour les tuples. Si la case est cochée pour les tuples, un fichier.java supplémentaire est crée. Celui-ci contiendra les accesseurs des attributs qui se trouvaient auparavant dans la classe correspondant à la vue. Figure 35 Client interface : Les méthodes que nous avons écrites peuvent être choisies. Ces méthodes implémentent l interface serializable. L interface serializable indique qu une classe peut être sérialisée, c est-à-dire qu un objet peut devenir persistant. L interface permet d envoyer ou de recevoir des objets au travers d inputstream et outpustream Client Row Interface : Contient des méthodes si dans le nœud java generate Java file de view row class est coché. Les vues sont décrites, comme les entités, dans un fichier XML et un ou deux fichiers java (cela dépend du fait que des propriétés d affichage aient été définies). Les liens vues reposent également sur un fichier XML. Les nœuds des propriétés de la fenêtre d édition des liens vues sont : Figure 36 View Objects : On définit la source et la destination du lien vue. Il s agit d attributs d objet vue ou d une association. 4 Traduit de l aide en ligne sur 73 Astrid von Wyl

22 Figure 37 View link SQL : Requête correspondante au lien vue. Figure 38 View link properties : Définition d accesseurs pour le lien vue. Figure 39 Les propriétés des attributs d une entité se transmettent normalement aux objets vues qui leur correspondent Composants modules Un composant module est composé d instances d objets vues. Dans le référentiel Oracle Designer, le module produit se présente ainsi : sur 73 Astrid von Wyl

23 Figure 40 Dans Oracle JDeveloper 10g, ce même module, une fois importé, a l apparence suivante : Voici l exemple de deux vues : Figure 41 Figure 42 Le contenu du composant module sera utilisé lors de l affichage de l application. Les propriétés du composant module sont : Data model : On choisit parmi les objets vues du projets ceux qui vont faire partie du composant. Chaque instance d objet vue a un nom différent qui est défini ici sur 73 Astrid von Wyl

24 Figure 43 Application module : Référence à un autre composant module qui se trouve dans le même projet. Java : Définition des fichiers java qui seront générés. Remote : Lorsque le déploiement de l application ne se fait pas en local, on peut choisir entre deux configurations : EJB session bean et J2EE web services. Figure 44 Client Interface : Choix des méthodes qui pourront être appelées par le client. Custom properties : Ajout de données dans les méta données. Lorsque je teste un module, le contenu du champ numero est incrémenté automatiquement mais le nombre est négatif et décrémenté au fur et à mesure des insertions. Selon le livre [DKF10g], la valeur affichée n a aucun rapport avec la valeur en cache. C est effectivement le cas. Dans la table, malgré que 4 ait été affiché, la valeur insérée est la valeur de la séquence. Il faut veiller à cliquer sur si on ne veut plus ajouter de nouvel enregistrement, sinon si on clique sur ajouter un nouvel enregistrement vide est créé et les contraintes not null provoquent des erreurs sur 73 Astrid von Wyl