Table des matières | Précédent | Suivant | Bas de page |
Sommaire |
---|
|
Ce chapitre définit les contributions infoset pouvant être liées aux
nœuds de donnée d'instance avec l'élément bind
(voir
3.3.4 L'élément bind
). La combinaison de ces contributions
à un nœud de donnée d'instance est appelée
élément de modèle. Prises ensemble, ces contributions sont appelées
propriétés d'élément de modèle ; elles
sont définies dans la section suivante. Par opposition, le terme
contrainte de schéma se rapporte seulement aux contraintes
du schéma XML issues des facettes d'un certain type de donnée.
On peut distinguer les propriétés d'élément de modèle selon divers axes.
Les expressions calculées par rapport aux propriétés fixes :
Les propriétés fixes sont des valeurs statiques que le processeur XForms n'évalue qu'une seule fois. Ces propriétés se composent de littéraux et ne sont pas soumises à une évaluation XPath.
Les expressions calculées sont des expressions XPath qui fournissent une valeur au processeur XForms. Ces valeurs sont recalculées à certains moments comme défini par le modèle de traitement XForms (cf. 4 Le modèle de traitement). Ces expressions codent des propriétés dynamiques, souvent des contraintes, telle que les dépendances entre les divers éléments de donnée. Les expressions calculées ne se limitent pas à l'examen de la valeur du nœud de donnée d'instance sur lequel elles s'appliquent. Les expressions XPath fournissent les moyens pour traverser les données d'instances ; on peut coder des calculs plus complexes comme des appels à des scripts externes.
Les règles d'héritage :
Certaines propriétés d'élément de modèle définissent des règles d'héritage, auquel cas le processeur XForms doit assurer le suivi de deux
valeurs séparées : d'une part, la valeur locale, qui est appliquée à partir d'un attribut de l'élément bind
,
et, d'autre part, la valeur héritée, qui est déterminée en combinant la valeur locale évaluée et les valeurs évaluées des
nœuds ancêtres dans les données d'instance.
Remarque :
L'exemple d'algorithme de recalcul défini dans D L'algorithme de séquence de recalcul est défini pour agir seulement sur les valeurs locales d'une propriété d'élément de modèle. Il suppose que l'implémentation propage les valeurs combinées aux descendants d'un nœud.
L'assignation des valeurs locales :
Les valeurs locales sont assignées en traitant tous les éléments bind
d'un modèle XForms dans l'ordre du document.
Une tentative de fixer deux fois la valeur d'une propriété d'élément de modèle sur le même nœud constitue une erreur. Les détails concernant
ce traitement se trouvent dans 4.2.1 L'événement xforms-model-construct
.
Les sections suivantes listent les propriétés d'élément de modèle disponibles pour tous les éléments de modèle. Pour chacune, on donne les renseignements suivants :
Description
Expression calculée (oui ou non)
Valeurs légales
Valeur implicite
Règles d'héritage
type
Description : associe un type de donnée de schéma.
Expression calculée : non.
Valeurs légales : toute valeur de type xsd:QName
représentant une définition de type de donnée dans un schéma XML.
Valeur implicite : valeur de type xsd:string
.
Règles d'héritage : ne s'hérite pas.
L'effet de cette propriété d'élément de modèle est le même que celui produit par un attribut xsi:type
placé sur les
données d'instance. Toutefois, contrairement à xsi:type
, la propriété type
peut s'ajouter aux éléments comme aux attributs.
<instance> <my:nom-personne> <my:prenom /> <my:nom xsi:type="my:chaineNonVide" /> </my:nom-personne> </instance> <bind type="my:chaineNonVide" nodeset="/my:nom-personne/my:prenom" />
Nous illustrons ici deux façons d'associer un type d'un schéma XML à un élément.
readonly
Description : indique si la valeur est interdite de changement.
Expression calculée : oui.
Valeurs légales : toute expression convertible en un type XPath boolean
avec la fonction boolean()
.
Valeur implicite : false()
, à moins qu'une propriété calculate
ne soit définie alors true()
.
Règles d'héritage : si un nœud ancêtre est évalué à true
, alors cette valeur est traitée comme true
. Sinon,
la valeur locale est utilisée.
Remarque :
Cela équivaut à prendre le OU logique de la propriété readonly
évaluée sur le nœud local et tous les nœuds ancêtres.
Lorsqu'elle est évaluée à true
, cette propriété d'élément de modèle indique au processeur XForms qu'il ne devrait pas autoriser de
changements au nœud de donnée d'instance lié.
Outre cette restriction sur les changements de la valeur, la propriété d'élément de modèle readonly
fournit une indication
à l'interface d'utilisateur XForms. Les commandes de formulaire liées aux données d'instance par la propriété d'élément de modèle
readonly
devraient indiquer que la saisie et la modification de la valeur ne sont pas permises. La présente spécification ne définit
aucun effet en ce qui concerne la visibilité, le focus ou l'ordre de navigation.
readonly
<instance> <my:nom-personne> <my:prenom>Roland</my:prenom> <my:nom/> </my:nom-personne> </instance> <bind nodeset="/my:nom-personne/my:prenom" readonly="true()"/>
Nous avons associé ici une propriété readonly
à un élément.
required
Description : définit si une valeur est obligatoire avant que les données d'instance ne soient soumises.
Expression calculée : oui.
Valeurs légales : toute expression convertible en un type XPath boolean
avec la fonction boolean()
.
Valeur implicite : false()
.
Règles d'héritage : ne s'hérite pas.
Un formulaire peut imposer certaines valeurs, et cette obligation peut être dynamique. Lorsqu'elle est évaluée à true
,
cette propriété d'élément de modèle indique qu'un nœud de donnée d'instance non vide est obligatoire avant que la soumission des
données d'instance puisse intervenir. On définit un nœud non vide ainsi :
Si le nœud de donnée d'instance est un élément, alors la valeur de son attribut xsi:nil
ne doit pas être fixée à true
;
La valeur du nœud de donnée d'instance lié doit être convertible en un type XPath string
avec une longueur supérieur à zéro.
Sauf indiqué ci-dessous, la propriété d'élément de modèle required
ne fournit aucune indication à l'interface d'utilisateur XForms
en ce qui concerne la visibilité, le focus ou l'ordre de navigation. Les auteurs XForms sont fortement encouragés de s'assurer que les
commandes de formulaire acceptant des données required
soient visibles. Un processeur XForms peut fournir une indication selon laquelle
une commande de formulaire est obligatoire et peut en rendre compte immédiatement, y compris en limitant la navigation. Le chapitre
4 Le modèle de traitement contient des précisions sur les moyens dont dispose le processeur XForms pour
faire respecter des valeurs obligatoires.
required
<instance> <my:nom-personne> <my:prenom>Roland</my:prenom> <my:nom /> </my:nom-personne> </instance> <bind nodeset="/my:nom-personne/my:nom" required="true()"/>
Nous avons associé ici une propriété required
à un élément my:nom
pour indiquer qu'une valeur doit être fournie.
Remarque :
Le schéma XML possède un concept nommé de manière similaire : use="required|optional|prohibited"
. Il diffère de deux façons
de la propriété d'élément de modèle XForms : premièrement, use
ne s'applique qu'aux attributs, tandis que le
required
de XForms s'applique à n'importe quel nœud et, deuxièmement, use
concerne le fait selon lequel
l'attribut entier doit être défini (sans tenir compte de la valeur), tandis que required
détermine si le nœud doit fournir une
valeur avant la soumission.
relevant
Description : indique si l'élément de modèle est couramment pertinent. Les nœuds de donnée d'instance ayant cette propriété
évaluée à "false
" ne sont pas sérialisés pour la soumission.
Expression calculée : oui.
Valeurs légales : toute expression convertible en un type XPath boolean
avec la fonction boolean()
.
Valeur implicite : true()
.
Règles d'héritage : si un nœud ancêtre est évalué à "false
" pour XPath, alors cette valeur est traitée comme "false
".
Sinon, la valeur locale est utilisée.
Remarque :
Cela équivaut à prendre le ET logique de la propriété relevant
évaluée du nœud local et de tous les nœuds ancêtres.
Beaucoup de formulaires ont des sections d'entrée de donnée qui dépendent d'autres conditions. Par exemple, un formulaire pourrait demander à l'interlocuteur s'il possède une voiture : lui demander d'autres renseignements sur sa voiture n'est approprié que s'il a indiqué en posséder une.
La propriété d'élément de modèle relevant
fournit à l'interface d'utilisateur XForms des indications concernant la visibilité,
le focus et l'ordre de navigation. En général, lorsqu'elle a la valeur "true
", les commandes de formulaires associées
devraient être rendues visibles. Inversement, pour la valeur "false
", les commandes de formulaire associées
(et tous les sous-éléments) et les éléments group
et switch
(et leurs contenus)
devraient être rendues indisponibles, retirées de l'ordre de navigation et ne pas pouvoir recevoir le focus.
Remarque :
Une commande de formulaire, un élément group
ou un élément switch
doivent exprimer une seule
liaison de nœud pour être associés à un nœud d'instance.
relevant
<instance> <my:commande> <my:article> <my:montant /> <my:rabais>100</my:rabais> </my:article> </my:commande> </instance> <bind nodeset="my:article/my:rabais" readonly="true()" relevant="../my:montant > 1000"/>
Nous avons associé ici une propriété relevant
à un élément my:rabais
pour indiquer qu'un rabais est pertinent
lorsque le montant de la commande est supérieur à 1000.
Le tableau suivant montre l'interaction d'interface d'utilisateur entre les propriétés required
et relevant
.
required="true()" |
required="false()" |
|
relevant="true()" |
La commande de formulaire (et ses sous-ensembles) doit être visible ou disponible pour l'utilisateur. L'interface d'utilisateur XForms peut indiquer qu'une valeur est obligatoire. | La commande de formulaire (et ses sous-ensembles) doit être visible ou disponible pour l'utilisateur. L'interface d'utilisateur XForms peut indiquer qu'une valeur est optionnelle. |
relevant="false()" |
La commande de formulaire (et ses sous-ensembles) doit être cachée ou indisponible pour l'utilisateur. L'entrée d'une valeur et l'obtention du focus devraient être interdits. L'interface d'utilisateur XForms peut indiquer, si la commande de formulaire devenait pertinente, qu'une valeur sera demandée. | La commande de formulaire (et ses sous-ensembles) doit être cachée ou indisponible pour l'utilisateur. L'entrée d'une valeur et l'obtention du focus devraient être interdits. |
calculate
Description : fournit une expression servant à calculer la valeur du nœud de donnée d'instance associé.
Expression calculée : oui.
Valeurs légales : toute expression XPath.
Valeur implicite : aucune.
Règles d'héritage : ne s'hérite pas.
Un modèle XForms peut contenir des éléments de modèle qui sont calculés à partir d'autres valeurs. Par exemple, la somme des articles sur une ligne pour la quantité fois le prix unitaire, ou le montant des taxes à payer sur une commande. On peut exprimer une telle valeur calculée comme une expression calculée en se servant des valeurs d'autres éléments de modèle. Le chapitre 4 Le modèle de traitement contient des précisions sur le moment et la manière dont le calcul s'effectue.
calculate
<instance> <my:commande> <my:article> <my:montant /> <my:rabais /> </my:article> </my:commande> </instance> <bind nodeset="my:article/my:rabais" calculate="../my:montant * 0.1" relevant="../my:montant > 1000"/>
Nous avons associé ici une propriété relevant
à l'élément my:rabais
pour indiquer qu'un rabais de 10% est pertinent
lorsque le montant de la commande est supérieur à 1000.
constraint
Description : définit un prédicat à satisfaire pour que le nœud de donnée d'instance associé soit considéré valide.
Expression calculée : oui.
Valeurs légales : toute expression convertible en un type XPath boolean
avec la fonction boolean()
.
Valeur implicite : true()
.
Règles d'héritage : ne s'hérite pas.
Lorsque l'évaluation XPath donne "false
", l'élément de modèle associé n'est pas valide ; l'inverse n'est pas nécessairement
vrai. Le chapitre 4 Le modèle de traitement contient des précisions sur le moment et la manière
dont la contrainte se calcule ainsi que le moment où la validation s'effectue.
constraint
<instance> <my:intervalle> <my:depuis /> <my:jusque /> </my:intervalle> </instance> <bind nodeset="my:jusque" constraint=". > ../my:depuis" />
Ici, une propriété constraint
associée à l'élément my:jusque
indique que la valeur de celui-ci doit être supérieure à
celle de l'élément my:depuis
.
Remarque :
On peut obtenir un minimum et un maximum d'occurrences pour les nœuds dans les données d'instance en se servant de la
fonction count()
dans une propriété constraint
.
p3ptype
Description : joint un élément de donnée P3P à un nœud de donnée d'instance, en indiquant le type de donnée particulier collecté là-bas.
Expression calculée : non.
Valeurs légales : xsd:string
.
Valeur implicite : aucune.
Règles d'héritage : ne s'hérite pas.
Cette propriété d'élément de modèle contient une description du type de donnée collecté par le nœud de donnée d'instance associé, fondée sur le système de type de donnée P3P [P3P 1.0]. Ces informations peuvent servir à améliorer la session de remplissage du formulaire en fournissant, par exemple, des données connues au préalable.
<instance> <my:nom-personne> <my:prenom /> <my:nom /> </my:nom-personne> </instance> <bind type="my:chaineNonVide" nodeset="my:prenom"p3ptype="user.personname.given"p3ptype="user.name.given"/>
Ici nous avons joint des informations concernant à la fois le schéma XML et le type P3P à l'élément my:prenom
via
un élément bind
.
Le chapitre 5 Les types de données décrivait la manière dont XForms utilise le système
de type de donnée du schéma XML pour contraindre l'espace de valeurs
des valeurs de données collectée par un modèle XForms. On peut fournir de telles contraintes de type de donnné via un schéma XML. Alternativement,
cette section liste divers mécanismes pour adjoindre des contraintes de type aux données d'instance. Les
attributs xsi:schemaLocation
et xsi:noNamespaceSchemaLocation
, pour la localisation des schémas, sont volontairement ignorés.
Le modèle de traitement XForms applique les facettes du schéma XML au cours du processus de validation. Au niveau le plus simple, il est nécessaire d'associer un ensemble de facettes (au travers d'un type de donnée du schéma XML) à un élément de modèle. Cela a pour effet de restreindre les valeurs admissibles du nœud de donnée d'instance associé aux représentations valides de l'espace lexical du type de donnée.
L'ensemble des facettes associé à un élément de modèle doit être déterminé par la liste suivante, comme si elle était traitée dans l'ordre donné. Lorsque plusieurs restrictions de type de donnée s'appliquent au même élément de modèle, la combinaison de toutes les restrictions en question doivent s'appliquer. Remarquez que l'on peut produire une combinaison de restrictions qui soit impossible à satisfaire ; on décourage aux auteurs cette pratique.
Un schéma XML associé aux données d'instance ;
Un attribut du schéma XML xsi:type
dans les données d'instance ;
Une contrainte XForms type
associée au nœud de donnée d'instance au moyen d'une
liaison XForms ;
Si aucune contrainte de type n'est fournie, le nœud de donnée d'instance a implicitement type="xsd:string"
(par défaut vers une règle de chaîne).
L'exemple suivant déclare un type de donnée basé sur le type xsd:string
avec une contrainte de facette supplémentaire.
<xsd:simpleType name="chaineNonVide"> <xsd:restriction base="xsd:string"> <xsd:minLength value="1"/> </xsd:restriction> </xsd:simpleType>
Ce nouveau type de donnée pourrait alors être associé à un ou plusieurs éléments de modèle au travers de l'une des méthodes soulignées ici.
<my:prenom xsi:type="my:chaineNonVide"/>
L'élément my:prenom
est défini comme étant de type my:chaineNonVide
.
<instance> <my:prenom /> </instance> <bind type="my:chaineNonVide" nodeset="/my:prenom"/>
Ici, nous avons joint une information de type à l'élément my:prenom
via un élément bind
. L'auteur XForms peut ainsi
étendre des schémas externes alors qu'il n'a pas la possibilité de les changer.
Table des matières | Haut de page |