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:
-
filtres et recherches ;
-
tris, vues et hiérarchies personnalisées ;
-
contraintes d'identité : clés primaires, clés étrangères et contraintes d'unicité ;
-
permissions détaillées pour créer, modifier, supprimer ;
-
permissions individuelles de niveau occurrence ;
-
comparaison et fusion détaillées ;
-
possibilité d'héritage au niveau de chaque occurrence (voir héritage standard ) ;
-
optimisations de performances et d'occupation mémoire.
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:appinfo>
<osd:table>
<primaryKeys>/pathToField1 /pathToField...n</primaryKeys>
</osd:table>
</xs:appinfo>
</xs:annotation>
|
Element |
Description |
Requis |
|
|
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. |
|
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.
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. | |
|
|
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 :
Pour des raisons de performance, les champs suivants sont automatiquement indexés :
|
Non. |
|
|
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". |
|
|
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". |
|
|
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". |
|
|
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". |
|
|
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: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="productRange" type="xs:string"/><!-- key -->
<xs:element name="productCode" type="xs:string"/><!-- key -->
<xs:element name="productLabel" type="xs:string"/>
<xs:element name="productDescription" type="xs:string"/>
<xs:element name="productWeight" type="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 :
-
Définir le filtre dans le schéma
-
Implémenter la classe en charge du filtre, qui étend
UITableFilter
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: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:
<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 |
|
|
Spécifie la sélection à effectuer, relativement au noeud courant. Examples :
Le chemin jusqu'au prédicat (par exemple
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 :
Pour la syntaxe XPath, voir : EBX.Manager XPath supported syntax . |
Yes. |
|
|
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. |
|
|
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. |
|
|
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. |
|
|
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
|
Non. |
|
|
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
|
Non. |
A l'aide de cette sélection, si on double-clique sur 'Frank Herbert' dans la table des auteurs ci-dessous :

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

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

Home > Models