Dégradation harmonieuse d'interfaces utilisateur - UsiXML

4.3.3 Intégration de PlastiXML comme plugin au sein d’une application de génération
d’interfaces basée modèle
L’idée de devoir concevoir une application spécialisée avec l’obligation de créer un éditeur
d’interface (graphique et textuel) constitue une charge supplémentaire. D’autant plus qu’il
vaille mieux que le langage généré ait un caractère « universel » afin de pouvoir l’utiliser sur
une grande quantité de plate-formes. De même, il serait intéressant de pouvoir disposer d’une
définition d’interface qui soit compatible avec la technique de génération basée modèle.
Or, il existe déjà un éditeur générant des interfaces en USiXML (cfr. infra), baptisé
GraphiXML. Cet outil permettant le support de différents plugins, il serait donc utile
d’envisager l’intégration de notre application dans cet environnement.
Les fichiers renfermant l’information sur les transitions comporteraient alors deux parties :
- une partie statique, comportant la définition des différentes fenêtres en USiXML
- une partie dynamique, stockant les transitions possibles entre les différentes fenêtres
(nous pourrions utiliser le mécanisme de RuleTerm 1 ou chaque action spécifierait une
transition selon une machine de Moore (même si cela comporte les inconvénients
soulevé plus haut))
De même, nous pourrions également étendre le champ de notre plugin aux interfaces à
présentations purement dynamique, en plus des interfaces à présentations pré-calculées. Au
lieu d’avoir comme action une transition entre présentations, nous aurions alors une fonction
de représentation qui reconstruirait l’interface souhaitée après transition.
1 http://api.openoffice.org/docs/common/ref/com/sun/star/ucb/RuleTerm.html
47