SVGround : cours SVG

XForms : modèle

Le modèle de MVC

Dans l’architecture MVC, le M signifie modèle, et ce modèle correspond en fait aux données de l’application. Dans le cadre de XForms, et donc des formulaires Web, ces données sont les valeurs récupérées suite au remplissage du formulaire.

Contrairement aux formulaires HTML, ce modèle n’est lié en aucune manière à l’interface utilisateur. Même sans interface utilisateur, on pourrait manipuler le modèle et savoir quelles sont les données demandées. C’est faisable à la main ou, plus interessant, par des programmes informatiques. En effet, les formulaires XForms sont censés pouvoir fonctionner dans toutes les situations et dans le cas où il n’y a pas d’écran disponible par exemple (si le formulaire est lu à haute voix), le modèle permet quand même de déterminer quelles sont les données demandées.

Le modèle comporte plusieurs parties : les données demandés, le type de ces données et les relations entre elles. Nous verrons ces deux dernières caractéristiques dans d’autres chapitres. Intéressons nous pour le moment à la base de formulaires XForms : la manière dont les données sont structurées.

L’élément model

XForms dépend d’un langage hôte, c’est à dire qu’il ne fonctionne pas tout seul, on doit l’inclure dans un autre langage. Les deux langages de prédilections pour XForms sont XHTML et SVG.

Comme un modèle n’est pas destiné à être affiché (seule la vue de MVC l’est), on l’inclut en générale dans la partie destinée aux définitions du langage hôte. Avec XHTML, il s’agit de l’élément head et avec SVG, l’élément defs. Bien sûr il ne s’agit pas d’une obligation puisque de toute façon le modèle ne sera jamais affiché, mais le mieux est de respecter cette logique.

XForms étant un langage différent de XHTML ou de SVG, il n’a pas le même espace de nom. L’espace de nom de XForms est : http://www.w3.org/2002/xforms (vous trouverez sur ce site une liste des espaces de nom).

Voici comment on déclare un modèle dans du XHTML :

]]>

On déclare l’espace de nom de XForms à la deuxième ligne, associé au préfixe xf. On peut bien sûr choisir un autre préfixe, celui-ci est seulement le plus utilisé.

Vous voyez qu’on donne aussi un identifiant à notre modèle. La raison est simple : on peut avoir plusieurs modèles correspondant à plusieurs formulaires et cet identifiant est très utile pour sélectionner le bon modèle. Voici un exemple où on utilise plusieurs modèles dans un document SVG :

]]>

Ainsi on peut séparer la page en plusieurs formulaires, chaque modèle ayant son propre modèle de données et ses propres relations entre elles.

Nous verrons plus tard comment on indique quel modèle utilisé. Sachez juste que par défaut, quand rien n’est indiqué, c’est le premier déclaré.

Dans le cas où on n’a qu’un modèle, on peut oublier l’identifiant puisqu’il n’y a pas d’ambiguité possible.

L’élément instance

Rentrons dans le vif du sujet. Les données de notre modèle sont contenus dans l’élément instance d’un modèle. Que contient l’élément instance ? Il contient un document XML qui est notre modèle : chaque élément et chaque attribut peut contenir des données.

La plupart du temps ce modèle est du XML sans espace de nom. Par exemple quelque chose du genre :

]]>

Le document peu avoir une complexité aussi grande que vous voulez. Il n’y a pas de limite de niveau d’imbrication, de nombre d’attribut, etc. Vous êtes totalement libre de choisir la manière dont vos données sont organisés.

Dans un document XHTML, cela donne :

]]>

Et voilà, votre modèle est (presque) prêt ! Basiquement, tous vos modèles auront cette forme.

Par contre, je vois que quelquechose vous tracasse. Qu’est ce que xmlns="" vient faire ici ? Cet attribut sert, comme vous le savez, à indiquer l’espace de nom d’éléments XML. Or, la plupart du temps, on désire des documents XML "bruts", sans espace de nom. C’est à cela que sert cet attribut.

D’ailleurs, si vous avez bien suivi le tutoriel XML, sans xmlns="", l’espace de nom du XML de l’instance est dans l’espace de nom de XHTML. Or il n’existe pas de tels éléments en XHTML… Sans être un bug, cela n’est pas logique, et les données soumises auraient alors le même espace de nom, avec la déclaration qui va avec.

On peut bien sûr utiliser des espaces de nom non nuls. Voici un exemple :

]]>

Dans ce cas, l’instance est au format SVG, et l’espace de est celui de ce langage. Aucun dessin ne sera affiché (le modèle ne s’affiche jamais) mais on manipulera bien un document SVG et on pourra par exemple, grâce à un contrôle, modifier la valeur de l’attribut width, avant d’envoyer le dessin au serveur.

Un dernier petit détail : comme pour les modèles, il peut y avoir plusieurs instances qui correspondent à différentes sources de données. De la même manière que pour l’élément model, on identifie ces différentes instances avec un identifiant (attribut id). Nous verrons plus tard comment sélectionner la bonne instance.

Préchargement de document

La première fonctionnalité sympa de XForms est la possibilité d’indiquer une source pour l’instance, plutôt que de l’écrire directement dans le document. Ainsi, si on appelle ce document inscription.xml :

]]>

On peut indiquer au processeur XForms d’aller chercher les données de telle instance dans ce fichier grâce à l’attribut src sur un élément instance :

]]>

Le résultat est le même que si on avait copié le contenu du fichier entre les deux balises de l’élément instance.

C’est très utile quand on doit charger la même instance dans plusieurs formlaires, par exemple la liste de pays ISO (qu’on peut trouver sur leur site). Un autre cas peut être de préremplir un formulaire lorsqu’un utilisateur est en cours de session un langage dynamique côté serveur comme PHP. Exemples :

]]>

Ainsi on a plusieurs instance prêtes à être affichées et modifiées par des éléments de contrôle… dont le prochain chapitre fait le tour !

XForms : introduction
Contrôles