Home > Models

Tables, filtres et noeuds de sélection

EBX.Platform supporte les caractéristiques des tables de bases de données relationelles en terme de volume élevé d'occurrences et d'identification par clé primaire.

Vis à vis des listes agrégées , les tables apportent de nombreux avantages. Au delà des aspects purement relationnels, voici quelques-unes des caractéristiques supportées:

Terminologie : les termes "enregistrement" et "occurrence de table" sont indifféremment utilisés dans cette documentation.

Définition de table

Un élément dont l'attribut maxOccurs est supérieur à 1 est déclaré en tant que table en ajoutant l'annotation qui suit : 

 <xs:annotation>
     <xs:appinfo>
         <osd:table>
             <primaryKeys>/pathToField1 /pathToField...n</primaryKeys>
         </osd:table>
     </xs:appinfo>
 </xs:annotation>

Element

Description

Requis

primaryKeys

Définit les clés primaires de la table. Chaque champ de la clé est dénoté au moyen de la notation XPath d'un chemin absolu qui débute juste sous l'élément racine de la table. Si la clé est composite, la liste des champs doit être séparée par des espaces.

Note : une gestion spécifique des espaces a été définie pour les clés primaires de type xs:string .

Oui.

defaultLabel

libellés par défaut à utiliser pour présenter chaque enregistrement dans une table ou dans une hiérarchie. Plusieurs variantes peuvent être définies simultanément : expression par défaut, expressions localisées, classe Java de rendu programmatique.

  • Expression par défaut et expressions localisées. Ces variantes sont définies au moyen de l'élément defaultLabel , par exemple : 

    <defaultLabel>Product : ${./ProductID}</defaultLabel>

    <defaultLabel xml:lang="fr-FR">Produit : ${./ProductID}</defaultLabel>

    <defaultLabel xml:lang="en-US">Product : ${./ProductID}</defaultLabel>

  • JavaBean qui implémente l'interface UILabelRenderer . Il est défini au moyen de l'attribut osd:class , par exemple : 

    <defaultLabel osd:class="com.wombat.MyLabel"></defaultLabel>

La dernière variante peut aussi être utilisée par les hiérarchies. Cette variante spécifie une classe qui doit alors implémenter l'interface UILabelRendererForHierarchy .

Pour plus d'informations au sujet des hiérarchies, veuillez consulter le chapitre Utiliser les perspectives .

No.

index

Propriété permettant d'indexer certains champs de la table ; l'indexation améliore le temps d'accès des requêtes portant sur ces champs (voir performances ).

Remarques : 

  • Il est possible de définir plusieurs index pour une même table.

  • Il n'est pas autorisé de définir deux index ayant le même nom.

  • Il n'est pas autorisé de déclarer deux index définissant exactement les mêmes champs.

  • Il n'est pas autorisé d'indexer un champ non terminal.

  • Il n'est pas autorisé d'indexer un champ liste ou situé sous une liste.

  • Les champs déclarés comme étant des attributs hérités ne peuvent pas être indexés.

  • Les champs déclarés comme étant calculés ne peuvent pas être indexés.

Pour des raisons de performance, les champs suivants sont automatiquement indexés : 

Non.

mayCreateRoot

Expression qui spécifie sous quelles conditions il est possible de créer une occurrence racine (voir modes de définition ). L'expression doit suivre la syntaxe ci-dessous.

Non, par defaut est "always".

mayCreateOverwriting

Expression qui spécifie sous quelles conditions il est possible de créer une occurrence de surcharge. (voir modes de définition ). L'expression doit suivre la syntaxe ci-dessous.

Non, par defaut est "always".

mayCreateOcculting

Expression qui spécifie sous quelles conditions il est possible de créer une occurrence d'occultation. (voir modes de définition ). L'expression doit suivre la syntaxe ci-dessous.

Non, par defaut est "always".

mayDuplicate

Expression qui spécifie sous quelles conditions il est possible de dupliquer une occurrence. L'expression doit suivre la syntaxe ci-dessous.

Non, par defaut est "always".

mayDelete

Expression qui spécifie sous quelles conditions il est possible de supprimer une occurrence. L'expression doit suivre la syntaxe ci-dessous.

Non, par defaut est "always".

Les expressions may... définissent sous quelles conditions l'action est possible. Cependant, les droits d'accès peuvent restreindre ces conditions de manière indépendante. Les expressions ont la syntaxe suivante : 

expression ::= always | never | <condition>*

condition ::= [root:yes | root:no]

condition ::= [agreement:yes | agreement:no]

condition ::= [agreementAscendant:yes | agreementAscendant:no]

"always" : la création est toujours possible (mais les droits d'accès peuvent restreindre cela).

"never" : la création n'est jamais possible.

"root:yes" : la création est possible si l'occurrence est dans une instance racine.

"root:no" : la création n'est pas possible si l'occurrence est dans une instance racine.

"agreement:yes" : la création est possible si l'occurrence est dans une instance de type accord.

"agreement:no" : la création n'est pas possible si l'occurrence est dans une instance de type accord.

"agreementAscendant:yes" : la création est possible si l'occurrence est dans une instance descendante d'un accord.

"agreementAscendant:no" : la création n'est pas possible si l'occurrence est dans une instance descendante d'un accord.

Si l'occurrence ne vérifie aucune des conditions spécifiées dans l'expression, la valeur par défaut est adoptée.

Ci-dessous figure un exemple de table produit dans un catalogue.

<xs:element name="productminOccurs="0maxOccurs="unbounded">
     <xs:annotation>
         <xs:documentation>
             <osd:label>Product Table </osd:label>
             <osd:description>List of products in Catalog </osd:description>
         </xs:documentation>
     </xs:annotation>
     <xs:complexType>
     <xs:annotation>
         <xs:appinfo>
             <osd:table>
                 <primaryKeys>/productRange /productCode</primaryKeys>
                 <index name="indexProductCode">/productCode</index>
             </osd:table>
         </xs:appinfo>
     </xs:annotation>
         <xs:sequence>
             <xs:element name="productRangetype="xs:string"/><!-- key -->
             <xs:element name="productCodetype="xs:string"/><!-- key -->
             <xs:element name="productLabeltype="xs:string"/>
             <xs:element name="productDescriptiontype="xs:string"/>
             <xs:element name="productWeighttype="xs:int"/>
         </xs:sequence>
     </xs:complexType>
</xs:element>

Les contraintes sur clé primaire de table sont définies au moyen des facettes étendues .

Les tables disposent dans EBX.Manager d'un éditeur dédié :

Spécifier des filtres sur une table

Par défaut, les tables affichent toutes leurs occurrences dans EBX.Manager. Cependant, l'utilisateur a la possibilité d'ajouter des filtres et d'afficher seulement les occurrences correspondant à des critères donnés.

Pour ce faire, vous devez suivre les étapes suivantes :

En résultat, nous obtenons un bouton qui apparaît à l'écran, qui donne à l'utilisateur la possibilité de filtrer sa recherche.

Un exemple d'implementation est présent dans la partie Tutoriel .

Noeud de sélection

Une déclaration d'élément peut définir une sélection XPath dynamique et contextuelle. Dans ce cas, l'interface utilisateur du Manager propose un lien de navigation qui permet d'accéder à une vue filtrée ou non.

Un noeud de sélection est, entre autres, utile pour matérialiser une association entre deux entités , d'une part dans l'interface utilisateur mais aussi potentiellement à des fins de validation. Par exemple, le schéma du tutoriel "bibliothèque" spécifie qu'un livre est écrit par un auteur (ce qui est rendu explicite au moyen d'une clé étrangère dans la définition du type complexe 'Book'). La relation inverse (un auteur a écrit certains livres) ne peut pas être exprimée facilement en schéma XML, sauf en insérant le noeud de sélection suivant dans la définition du type complexe 'Author' : 

<xs:element name="linkToAuthorTitlesminOccurs="0maxOccurs="0type="xs:string"> 
   <xs:annotation> 
      <xs:appinfo> 
         <osd:select> 
             <minOccurs>1</minOccurs> 
             <maxOccurs>10</maxOccurs> 
             <xpath>/root/Titles[au_id =${../au_id}]</xpath> 
         </osd:select> 
      </xs:appinfo> 
   </xs:annotation> 
</xs:element>

L'élément minOccurs précise que pour être valide, un auteur doit avoir écrit au moins un livre.

L'élément maxOccurs précise que pour être valide, un auteur doit avoir écrit au maximum dix livres.

A noter que nous devons conserver les contraintes de cardinalité "officielles" du noeud ( minOccurs="0" maxOccurs="0" ) : elles sont nécessaires car, d'un point de vue XML externe (document instance du schéma XML), le noeud n'a aucune occurrence. Autrement dit, un noeud de sélection est un élément "virtuel" vis à vis de XML et XML Schema.

Il est en outre possible de spécifier une contrainte additionnelle sur la relation. Dans l'exemple qui suit, chaque relation entre un auteur et un livre est valide, si la date de publication du livre est antérieure à la date de décès de l'auteur:

    <osd:select> 
       <xpath>/root/Titles[au_id =${../au_id}]</xpath> 
       <constraintPredicate>date-less-than(datePub, ${../death})</constraintPredicate> 
       <constraintPredicateErrorMessage>a default error message</constraintPredicateErrorMessage> 
       <constraintPredicateErrorMessage xml:lang="fr-FR">a french default error message
       </constraintPredicateErrorMessage> 
       <constraintPredicateErrorMessage xml:lang="en-US">a US default error message
       </constraintPredicateErrorMessage> 
    </osd:select> 

Element

Description

Obligatoire

xpath

Spécifie la sélection à effectuer, relativement au noeud courant.

Examples :  /root/Titles[au_id =${../au_id}] or //Titles[au_id =${../au_id}] or ../Titles[au_id =${../au_id}]

Le chemin jusqu'au prédicat (par exemple ../Titles ) spécifie la table cible à filtrer. Cette partie du chemin est résolue relativement à la racine de la table contenant.

Si la sélection dépend de l'état de l'occurrence à laquelle la sélection est attachée, les expressions primaires du prédicat feront référence aux valeurs de l'occurrence locale en utilisant la notation :  ${ <relative-path> }relative-path est un chemin qui localise l'élément relativement au noeud qui détient le lien de sélection.

Pour la syntaxe XPath, voir : EBX.Manager XPath supported syntax .

Yes.

container

Optionnel, référence de l'instance qui contient la table cible.

Non, si cet élément n'est pas spécifié, l'instance est celle contenant la table.

minOccurs

Spécifie une contrainte de validation additionnelle : la sélection doit être au moins de la taille spécifiée.

Non, la valeur par défaut est 0.

maxOccurs

Spécifie une contrainte de validation additionnelle : la sélection doit au plus être de la taille spécifiée.

Non, par défaut la taille maximum n'est pas restreinte.

constraintPredicate

Spécifie une contrainte de validation additionnelle : toute relation qui satisfait la sélection doit aussi satisfaire la contrainte XPath spécifiée. La notation ${ <relative-path> } a la même signification que pour l'élément xpath (voir ci-dessus).

Non.

constraintPredicateErrorMessage

Spécifie le message d'erreur à afficher quand le prédicat de contrainte n'est pas satisfait. Ce message peut être localisé au moyen de l'attribut standard xml:lang

Non.

A l'aide de cette sélection, si on double-clique sur 'Frank Herbert' dans la table des auteurs ci-dessous :

o1

on obtient le lien [linkToAuthorTitles] ci-après dans le formulaire de l'auteur sélectionné et si on sélectionne ce lien,

o2

on est redirigé sur la vue filtrée des titres de cet auteur :

o3

Home > Models