XRX, un doux rêve ?
Par Laurentj le vendredi, septembre 11 2009, 14:30 - Technologies Web - Lien permanent
Tangi vient de publier un billet très intéressant sur une nouvelle façon de faire une application web, une architecture XRX, qui utilise XForms, Rest, et XQuery. Vu de loin, ce triplet à l'air sexy, et fait renaître l'idée de faire du XML de bout en bout, sans avoir à taper une ligne de code "fonctionnelles". Et pour Tangui, cela apporte beaucoup de simplicité par rapport au triptique Javascript/PHP/MYSQL. Sur ce point, je ne suis pas d'accord avec lui.
Comme Tanguy, j'avais noté la supériorité de XForms sur Ajax. Seulement je reconnais, avec le recul, qu'apprendre XForms n'est pas si évident que ça. Ça devient compliqué à utiliser dés que l'on veut faire un "vrai" formulaire (un truc complexe comme dans la vraie vie quoi). Et c'est je pense une des raisons principales de sa relative confidentialité, en plus du fait qu'il est aussi compliqué à implémenter, d'où son absence dans les navigateurs. Il faut aussi noter l'aspect verbeux des langages XML en général, qui en rebute plus d'un.
XForms est d'autant plus compliqué à utiliser, qu'il faut la plupart du temps indiquer un schema XML Schema pour valider le contenu XML généré ou lu par XForms (ce contenu sert de moyen de stockage des valeurs des champs de saisie). Et XML Schema est, comment dire, chiant à écrire, imbitique, complexe, pour la majorité des développeurs. Comme dit Daniel, XML Schema (avec XSLT), est la preuve de l'existence du diable. Et de mon avis, on est très loin de la simplicité de RelaxNG.
Qui dit XForms et XQuery, dit XPath. Dommage que la syntaxe des sélecteurs CSS n'avait pas servie de base lors de la spécification de XPath, XPath ne serait pas un truc aussi peu intuitif à utiliser.
Ajoutons XQuery donc pour cette architecture XRX. Je ne connais pas XQuery, donc je vais m'abstenir d'en dire du bien ou du mal, mais j'ai comme une appréhension d'aller lire la spécification...
Bref, utiliser des langages déclaratifs plutôt que programmatifs pour générer et manipuler du contenu, pourquoi pas. Mais j'ai peur qu'on n'ait pas encore de langage suffisamment simple pour le commun des développeurs. Ou alors d'outils de développement suffisamment puissants pour cacher la complexité (possible que ça existe remarquez...)
Alors je sais que faire de l'ajax, ce n'est pas forcément simple, mais il faut reconnaitre que les bibliothèques javascripts d'aujourd'hui aident beaucoup. Et puis, pour un développeur qui a fait des études dignes de ce nom, utiliser PHP/JAVA/whatever ou javascript est "normal".
J'aimerais quand même une implémentation native de XForms dans les navigateurs, parce que j'aime bien XForms dans sa philosophie. Mais avec HTML5 et ses webforms 2 qui débarquent, il va me falloir attendre encore longtemps.
Commentaires
Grâce à mon produit XSLTForms, j'arrive maintenant à faire de vrai formulaires relativement complexes.
Ce qu'il me reste à implémenter est un mécanisme de sous-formulaires de manière à ce que tout ne soit pas fait en un seul formulaire. C'est autant une question de temps de réponse convenable que de complexité.
Je ne suis pas de l'avis qu'il s'agit de technologies plus compliquées mais il est certain qu'elles sont très différentes en terme de façon de penser. Ce serait comme de comparer SQL à Java, il faudrait plutôt parler d'une autre génération de langages. C'est déjà un problème de formation, à la base. Peut-être sont-elles à la portée d'autres profils de "programmeurs"...
En tout cas, un support natif de XForms sur les navigateurs n'est certainement pas pour demain. Et ça ne me semble pas si grave quand je vois que XSLTForms tourne tout aussi bien sur FireFox, Internet Explorer, Opera, Safari, Chrome, ...
-Alain
XRX / NXD XOrion Project
(Il y a déjà deux français: Alain Couthures et moi-même)
Ce n'est pas un rêve. Le produit est adopté par Mark Logic
HTML 5 - Attention complètement écrit en ligne par Google et Apple - Allez donc savoir pourquoi ?