xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: questions XForms
From: Robin Berjon (robin.berjon@expway.fr)
Date: 30/09/2003 - 19:55
Bonjour,
Thierry - listes wrote:
> 1) XForms côté serveur.
>
> Je suis assez surpris de n'avoir rien vu dans cette spécification
> qui décrive ce qui doit se passer du côté serveur.
Pouvez-vous fournir des exemples de ce que vous attendriez de la spécification à
ce sujet? Il existe des implémentations utilisant XForms sur le serveur, avec
diverses fonctionalités, mais en quoi devraient-elles être contraintes par la
spécification? Libre à chacun d'utiliser les informations contenues dans un
document XForms pour en faire ce qu'il veut :)
> Tout se passe comme si les implémentations XForms ne devaient jamais
> être rien d'autre que des plug-in pour des navigateurs Web
Il est vital dans ce type de technologie de garantir l'interopérabilité des
clients. Ce qu'ensuite chacun choisi de faire d'un document XML ne tombe pas
sous le coup de la spécification.
Aussi, le but d'XForms n'est pas d'être un plugin mais plutôt de se voir mélangé
à d'autres vocabulaires XML comme XHTML ou SVG, le plugin étant la solution de
contournement en attendant mieux. Par exemple, le SVG WG planche actuellement
sur des moyens d'intégrer XForms élégamment à SVG (ce qui devrait être
directement possible en utilisant les capacités d'extension, le support XPath,
et les évènements arbitraires dans SVG 1.2).
> (pour ne pas dire pour IE, vu le retard des autres sur XML).
Ouhla, je n'irai pas si loin. Il est beaucoup plus probable de voir une
implémentation native de XForms dans Mozilla bientôt que dans IE, qui est plutôt
en retard du coté XML. N'oublions pas non plus que IE est un produit mort.
> Elle semble certes assez précise pour décrire ce qui doit être envoyé au serveur
> quand le cas se produit (certains 'submit'), pour penser que c'est suffisant,
> charge au composant côté serveur de faire ce qu'il veut de cette "XML instance" par
> exemple.
C'est ce qui suffit à l'interopérabilité.
> Toutefois pourquoi ne pas réfléchir sur ce qui se passe ensuite et tenter de
> boucler
> la boucle (?) : idem pour la génération de XForms du serveur vers le client.
Je ne vois pas comment il serait possible d'aller plus loin de ce coté. Un
programme coté serveur reçoit ce qui a été soumis par le XForms, et en fait ce
qu'il veut. Peut-être mettre à jour une DB, peut-être envoyer un mail, peut-être
générer une carte des bistros sympa rue des Bluets... Comment tout celà pourrait
être spécifié?
> Je pense, en particulier (mais tout de même assez général de nos jours),
> à une liaison automatique vers un SGBDR.
C'est un domaine qui peut avoir son intérêt (bien que pas pour moi) mais je ne
vois pas comment XForms pourrait spécifier ça de façon générique et utilisable
par tous -- le format de ce qui est soumis varie de par trop, et l'applicabilité
à une SGBDR ne concerne qu'un tout petit sous-ensemble.
Il faut bien comprendre que XForms est beaucoup plus qu'un moyen de créer des
forms en XML, c'est un langage complet qui permet l'édition de XML arbitraire.
Il est tout à fait envisageable de charger un document XML comme instance
peuplant un form, de le modifer via ce form, et de le soumettre à nouveau,
réglant ainsi l'atroce problème de l'édition de documents en ligne utilisant des
textareas.
Pour en revenir aux SGBDR, un workflow que j'aimerai utiliser serait d'éditer
une instance XML avec XForms, de la soumettre dans une collection en utilisant
un PUT (ce qui est possible en XForms), et de l'interroger via XQuery. Nous
voilà libérés -- enfin! -- de toutes ces saloperies de SGBDR qu'il nous faut
aujourd'hui utiliser sur le Web. Tout en devient bien plus simple.
> Quand, dans XForms, on signale un champ "required", cela a-t-il un sens uniquement
> du côté client, ou peut-on en déduire des implications vers une BD ?
Les champs required sont signalés par le truchement d'un schema. Un des
avantages de XForms est que l'on peut utiliser le même schema sur le client et
sur le serveur.
Si vous avez besoin d'un accès plus automatique aux instances soumises via
XForms, il existe une large variété d'outils générant du code à partir d'un
schema ce qui permettrait d'utiliser une instance soumise comme s'il s'agissait
directement d'objets.
> De même d'autres caractéristiques sont-elles prévues (?) : par exemple,
> un auto-incrément de base de données.
Ce genre de chose me semble très spécifique à certaines utilisations.
> 2) Possibilités graphiques et caractéristiques côté client
>
> Dans les 2 cas, il semble que l'utilisation d'outils de ce type
> permette d'améliorer les possibilités graphiques réalisables
> simplement à l'aide de HTML/javascript.
> Toutefois cela est-il imposé par la spécification XForms ?
Nullement. L'exemple de SVG montre qu'il est possible par exemple de mettre à
jour une instance XForms en cliquant sur un rectangle rouge. Le rendu graphique
est completement séparé de la structure.
> A votre connaissance, quels sont les problèmes impossibles à résoudre
> si on envisage de rester en HTML/javascript pour réaliser un composant
> répondant à la spécification XForms ?
Ce qui sera difficile ce sera le support XPath et le routage des évènements. Il
y a des chances pour que ces deux choses soient accessibles sous Mozilla, de
façon disparate ailleurs, et pas du tout sous IE. XPath est implémentable en
Javascript, mais DOM Events sera plus difficile.
Il me semble plus simple d'utiliser un client SVG 1.2 pour ceci (en imaginant un
soit un déploiment controlé, soit un déploiement ouvert vers la fin de l'année
prochaine -- les clients SVG 1.1 ayant aujourd'hui une pénétration d'environs
70% et se mettant à jour tout seuls, il n'y a pas de raison de penser qu'il n'en
aille pas de même pour les clients 1.2).
> (En particulier, les 'submit' successifs ne provoquant pas d'aller-retour
> serveur sont-ils possibles à gérer ?).
En faisant des choses pas très jolies dans un iframe peut-être?
> 3) Contraintes de XForms et Pérénité des plug-in de navigateur
>
> Selon vous, quels sont les freins à la réussite de XForms ?
Une partie minoritaire mais vocale de la communauté Web les trouve trop
complexes. Ce n'est pas tant sa faute que celle de la spécification qui ne
montre pas assez les utilisations dites de "lazy authoring" qui sont aussi
simple voir plus que les utilisations des forms HTML. Il semblerait que ce
problème se résorbe peu à peu.
Aussi, l'utilisation encore majoritaire de IE malgré les annonces de Microsoft
le donnant pour mort. C'est là probablement le plus grand frein au développement
du Web en général. Autant je fus heureux d'abandonner Netscape pour IE quand il
était plus proche des standards, autant il est grand temps d'abandonner IE.
Continuer de l'utiliser c'est se faire soi-même frein au changement du Web, qui
comme nous le savons tous est malheureusement le domaine qui avance le plus
lentement de tout ce que couvre l'informatique.
> Dans cette idée de déporter côté client des traitements lourds pour le serveur,
> pourquoi le W3C n'a pas davantage poussé à l'utilisation de processeur XSLT
> côté client ?
Le W3C serait très heureux que les gens utilisent plus XSLT sur le client, mais
c'est malheureusement impossible.
> Encore aujourd'hui, seul IE le fait correctement.
Hmmm, si correctement signifie aléatoirement, je suis relativement d'accord :)
> XForms étant une surcouche de XML/XSL, est-il réaliste de tenter de faire
> ces deux étapes en une seule, alors que la première n'a pas été un succès ?
> (Dans ce cadre, peut-être le W3C compte-t-il sur les plus des aspects graphiques
> ?).
XForms n'est pas une surcouche XML/XSLT, il serait impossible de l'implémenter
complétement ainsi. Quid des évènements et de la validation?
> J'ai lu quelquepart que XForms sera (ré-) intégré à XHTML 2.0.
Probablement en effet. Ou plutôt, XHTML 2.0 ne formulera peut-être pas de forms.
> Dans ce cas, IE a déjà au moins 2 ans d'avance, et MS peut se contenter d'attendre.
Pardon? Si une simple feuille CSS permet d'utiliser XHTML 2.0 dans Mozilla,
l'équivalent IE laisse à désirer (bien qu'il est possible).
> Et si tous les navigateurs sont appelés à implémenter XForms,
> quelle est la pérénité des plug-in actuels ?
Cette question concerne ceux qui les produisent, pour les utilisateurs il est
possible d'utiliser les plugins pour le moment, et de voir plus tard ce qu'il se
passe.
--
Robin Berjon <robin.berjon@expway.fr>
Research Scientist, Expway http://expway.com/
7FC0 6F5F D864 EFB8 08CE 8E74 58E6 D5DB 4889 2488
--
Devenez redacteur <XML>fr et contribuez au developpement
du xml francophone (http://xmlfr.org/infos/redacteurs) !
Liste de diffusion "xml-decid@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet lie a XML.
Pour resilier votre abonnement, envoyez un message contenant la
commande "unsubscribe" a xml-decid-request@xmlfr.org
(mailto:xml-decid-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 30/09/2003 - 20:02 UTC
webmaster@xmlfr.org
| 
