xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: questions XForms
From: Alexandre Ardhuin (aardhuin@gfi.fr)
Date: 01/10/2003 - 14:56
Bonjour,
>
> Bonjour,
>
> Je viens de survoler la spécification XForms
>
> [proposition de recommandation :
> http://www.w3.org/TR/2003/PR-xforms-20030801/
> http://www.w3.org/MarkUp/Forms/
> ].
>
> Et je me pose quelques questions.
>
>
> 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.
Ceci par ce que rien ne doit se passer coté serveur tout simplement...
XForms est une norme qui a été créée pour répondre à l'évolution naturelle
des formulaires (qui ne savait rien faire :) ).
En particulier, XForms aborde la définition des champs de formulaire. Cela
dans le but de factoriser les contrôles de saisies (qui sont fait soit coté
client en utilisant des scripts, soit coté serveur ce qui augmente le nombre
d'aller-retour sur le réseau).. De plus ces contrôles sont en général
toujours les mêmes(ex: champs obligatoires, des nombres compris dans un
certain intervalle... ).. Ainsi, en théorie, plus besoin de faire des
scripts pour contrôler des choses basiques... On laisse le travaille au
navigateur...Faire un maximum de pré-controles des informations saisies sur
le poste client aura pour conséquence de grandement réduire le trafic réseau
. Bien entendu, les contrôles cotés serveurs ne doivent pas disparaître...
> Tout se passe comme si les implémentations XForms ne devaient jamais
> être rien d'autre que des plug-in pour des navigateurs Web
Le but, c'est que les navigateurs implémentent cette spécification et non
qu'il devienne la foire au plug-in...
> (pour ne pas dire pour IE, vu le retard des autres sur XML).
PAS D'ACCORD DU TOUT.
Je dirais même que c'est IE le plus en retard dans le support des normes...
Essayez par exemple de faire afficher du SVG ou du MathML nativement dans
IE....
Faites pareil sur Mozilla : OHHHH miracle, ça marche.... ;-)
Mais je m'égare, désolé...
> La spécification est très précise pour les comportements côté client.
> 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.
> 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 pense, en particulier (mais tout de même assez général de nos jours),
> à une liaison automatique vers un SGBDR.
> 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 ?
> De même d'autres caractéristiques sont-elles prévues (?) : par exemple,
> un auto-incrément de base de données.
XForms est juste une version plus puissante des formulaires.
Mais tout ceci régit uniquement ce qui doit se passer coté client.
> Il me semble que l'intérêt de XForms réside aussi (et surtout) dans la
possibilité
> d'utiliser des composants standards dans les applications Web pour générer
des
> formulaires.
> Qu'en pensez-vous ?
Effectivement, XForms permet de structurer l'information(contrairement au
formulaires actuels).
Ainsi, on peut imaginer facilement que la génération de formulaire XForms
sera grandement facilité par le fait que les données coté client seront
structurées de la même manière que dans un langage object coté serveur.
> Il se trouve que j'ai réalisé, lors d'une mission en 2001 sur un Intranet
> applicatif,
> un composant JAVA/XML/XSL (+ javascript pour le côté purement client)
> embrassant les 2 côtés (client et serveur) et qui était un générateur
> d'écrans (XML transformé suivant option, côté serveur par Xalan ou côté
client par
> MSXML)
> de management de tables simples (ou vues) de base de données.
>
> J'aurais aimé avoir quelques éléments supplémentaires de comparaison.
> Toute information sur le sujet serait la bienvenue.
> Avez-vous déjà été confronté à de telles réflexions ou vu des outils
similaires ?
> Merci.
>
>
> 2) Possibilités graphiques et caractéristiques côté client
>
> J'ai pu tester FormsPlayer, qui s'installe en plug-in pour IE+MSXML.
> Je n'ai par contre pas réussi à télécharger XFE de e-xmlmedia.com
> (il semble y avoir un problème sur le site).
> Ce dernier apporte ses possibilités côté client après le chargement d'une
applet.
>
> 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 ?
> (ou bien simplement rendu possible).
Le but premier de XForms(tout comme les formulaires) c'est de gérer
l'information et non de l'habiller.
> 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 ?
> (En particulier, les 'submit' successifs ne provoquant pas d'aller-retour
> serveur sont-ils possibles à gérer ?).
Xforms s'intégre à du code (X)HTML . Il remplace simplement les formulaires.
> 3) Contraintes de XForms et Pérénité des plug-in de navigateur
>
> Selon vous, quels sont les freins à la réussite de XForms ?
>
> 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 ? Encore aujourd'hui, seul IE le fait correctement.
> 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
> ?).
>
> J'ai lu quelquepart que XForms sera (ré-) intégré à XHTML 2.0.
> Dans ce cas, IE a déjà au moins 2 ans d'avance, et MS peut se contenter
d'attendre.
> Et si tous les navigateurs sont appelés à implémenter XForms,
> quelle est la pérénité des plug-in actuels ?
> Et le terme "XForms" aura-t-il encore un sens à ce moment là ?
>
>
> 4) Infopath
>
> Sur le site xmlfr, j'ai lu qu'on pouvait considérer Infopath comme
concurrent
> de XForms. (Il me semble d'ailleurs qu'Infopath prend en compte les
aspects
> serveur).
> Mais je crois qu'Infopath est actuellement un outil à part entière
> possédant sa propre interface.
> Savez-vous si MS envisage l'intégration de Infopath dans IE ?
>
http://xmlfr.org/actualites/decid/030813-0001
>
> En vous remerciant par avance de toute réponse.
>
>
> bye - Cdlt,
>
> Thierry GAGNAIRE
> mailto:thga@tgagnaire.com
>
>
Pour conclure, XForms est juste une amélioration des formulaires HTML pour
les données beaucoup plus de pouvoir....
Alexandre.
--
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 31/10/2003 - 09:52 UTC
webmaster@xmlfr.org
| 
