From: Dpi (dezon@club-internet.fr)
Date: 06/01/2004 - 22:40
> Ok pour tout cela, mais le fait de disposer d'une interface
> déclarative ne va t'il pas à l'encontre d'une séparation claire des
> données, présentation et traitements type MVC à l'instar de ce que
> l'on peut trouver en XML UI par exemple ?
>
Je ne connais pas XML UI. Xforms permet une bonne séparation
données-présentation: les controles référencent les données par une
expression XPath ou un id (on peut difficilement faire moins), et les
données ne connaissent pas la présentation. Concernant les traitements,
XForms a un modèle de traitement implicite à base d'évènements, qui fait
que peu de traitements sont explicites dans un formulaire XForms.
C'est justement la que le bas blesse me semble t'il, les normes XML UI
permettent de séparer complètement données, présentation ET traitement.
De plus, elles intègrent (pour la plupart) des possibilités
événementielles complètes :
- gestion des events sur les fenêtres et les objets
- sauvegarde des contextes applicatifs locaux avec échanges ou pas de
données (et uniquement
des données) avec le serveur et le tout au format XML.
De la même façon que xForms, les traitements XML UI sont limités au
minimum mais laissent la possibilité de mettre en oeuvre (par exemple)
des moyens de communications entre plusieurs fenêtres comportant chacun
des formulaires différents etc etc...
> Ce qui au passage permet de résoudre certains problèmes de découpages
> de formulaires justement cités précédemment.
>
> Je suis un peu déçu, car Il me semble, sauf erreur, que XForms soit
> (encore/toujours) très orienté formulaires et que cela apporte une
> certaine complexité sans apporter de solution de fond.
>
C'est clairement orienté formulaire et client (comme les forms HTML). On
peut généralement faire ce qu'on fait en XForms avec des technos plus
basiques (genre JavaScript), c'est d'ailleurs ce que fait InfoPath, qui
est moins déclaratif et utilise plus de scripts pour aboutir à des
fonctionnalités similaires. Est-ce que c'est plus ou moins complexe?
C'est une question de goût. Ca ne résout pas de problèmes coté serveur
(sauf lorsqu'on est allergique à JavaScript et qu'on essaie de faire
validation et dynamicité coté serveur).
Je voyais XForms plus proche de XAML que de InfoPath, mais je pense
maintenant être dans l'erreur quant à cette assertion.
En tous les cas merci de vos réponses qui m'ont éclairés sur le sujet.
Pierre
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 30/12/2003
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.557 / Virus Database: 349 - Release Date: 30/12/2003
--
Devenez redacteur <XML>fr et contribuez au developpement du
xml francophone (http://xmlfr.org/infos/redacteurs/) !
Liste de diffusion "xml-tech@xmlfr.org" (http://xmlfr.org).
Cette liste est a votre disposition pour discuter en francais de
tout sujet technique lie a XML.
Pour resilier votre abonnement, envoyez un message contenant
la commande "unsubscribe" a xml-tech-request@xmlfr.org
(mailto:xml-tech-request@xmlfr.org?Subject=unsubscribe)
Archive générée par hypermail 2.1.3 le 28/06/2004 - 11:06 UTC
webmaster@xmlfr.org
| 
