xml decid : Stratégies, marchés, affaires autour de XML.
[xml-decid] Re: questions XForms
From: Eric van der Vlist (vdv@dyomedea.com)
Date: 30/09/2003 - 16:17
Bonjour,
On Tue, 2003-09-30 at 17:17, Thierry - listes wrote:
> 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.
XForms est avant tout la prochaine génération des formes sur le web
appelée à remplacer les bonnes vieilles formes HTML. C'est donc une
spécification qui vise le client web même si, en guise de contournement,
on peut l'utiliser sur un serveur.
> Tout se passe comme si les implémentations XForms ne devaient jamais
> être rien d'autre que des plug-in pour des navigateurs Web
Je pense que le W3C préférerait voir des implémentations natives dans
les navigateurs, mais c'est effectivement un risque.
> (pour ne pas dire pour IE, vu le retard des autres sur XML).
Retard des autres? Aujourd'hui il me semble que c'est IE qui est en
retard sur le support de XML, mais on s'écarte du sujet ;-) ...
> 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 (?)
Parce que cela s'appuie entièrement sur HTTP et n'a pas lieu d'être
re-spécifié.
> : idem pour la génération de XForms du serveur vers le client.
Ce n'est pas le but de XForms mais plutôt un contournement que le W3C ne
doit pas spécialement souhaiter voir perdurer.
> 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.
>
> 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 ?
Oui, c'est pour cela que XForms s'appuie entièrement sur HTTP... Que
peut-on souhaiter de plus standard?
> 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 ?
Non, la spécification XForms a cherché à rester neutre en ce qui
concerne le rendu graphique.
En vous remerciant par avance de toute réponse.
>
>
> bye - Cdlt,
>
> Thierry GAGNAIRE
> mailto:thga@tgagnaire.com
>
>
>
> --
> 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)
> (ou bien simplement rendu possible).
> 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 ?).
>
>
> 3) Contraintes de XForms et Pérénité des plug-in de navigateur
>
> Selon vous, quels sont les freins à la réussite de XForms ?
Un manque d'implémentations natives.
> 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 ?
Pour des applications de saisie, XForms est plus souple que XSLT.
En ce qui concerne la transformation côté client, elle fonctionne
maintenant dans tous les navigateurs récents, mais ce n'est pas une
solution universelle. Si par exemple les documents XML manipulés pour
générer une page HTML sont volumineux, la transformation côté client
peut conduite à une augmentation importante du trafic réseau.
De plus, le W3C n'a aucun pouvoir sur les sociétés qui implémentent des
navigateurs!
> Encore aujourd'hui, seul IE le fait correctement.
???
> XForms étant une surcouche de XML/XSL,
Non, XForms ne s'appuie pas sur 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
> ?).
A mon avis, le W3C compte plus sur une simplification du développement
(éviter de devoir programmer en HTML + JavaScript + langage serveur et
sur des fonctionnalités impossibles à réaliser actuellement (saisie hors
ligne notamment).
> 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 ?
Qu'importe si on peut les désinstaller et utiliser le support natif s'il
arrive un jour?
> Et le terme "XForms" aura-t-il encore un sens à ce moment là ?
Je ne vous suis plus!
>
> 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 ?
Pas à ma connaissance. Il me semble que Microsoft se désengage du web
tel que nous le connaissons, c'est à dire bâti autour du navigateur pour
construire quelque chose d'autre (plus riche et sans doute plus
propriétaire) (beaucoup d'indices semblent converger vers cette
interprétation, mais ce n'est qu'une interprétation personnelle).
Cordialement,
Eric van der Vlist
--
If you have a XML document, you have its schema.
http://examplotron.org
Upcoming schema tutorial:
- Philadelphia (7/12/2003) http://makeashorterlink.com/?V28612FC5
Tutoriel XSLT:
- Paris (25/11/2003) http://makeashorterlink.com/?L2C623FC5
------------------------------------------------------------------------
Eric van der Vlist http://xmlfr.org http://dyomedea.com
(W3C) XML Schema ISBN:0-596-00252-1 http://oreilly.com/catalog/xmlschema
------------------------------------------------------------------------
--
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
| 
