jForms devient extensible
Par Laurentj le dimanche, janvier 27 2008, 14:58 - Projets - Lien permanent
Dés le départ, quand j'ai conçu l'architecture du système de formulaire jForms, dans Jelix, j'ai fait en sorte que chaque partie de jforms soit suffisamment bien séparée des autres, de manière à le faire évoluer le plus facilement possible. Par exemple, un des objectifs premiers était, à partir d'un unique fichier descriptif de formulaire en XML, de pouvoir générer un formulaire dans le format que l'on veut : HTML, XUL, XForms etc.. Ainsi donc, dans jForms il y a
- un objet pour l'analyse du fichier XML jforms
- un ensemble d'objet pour l'instanciation et la manipulation d'un formulaire coté serveur dans les contrôleurs,
- d'autres pour la validation des données coté serveur,
- et enfin un autre pour la génération finale d'un formulaire dans un format précis.
Dans Jelix 1.0.1, il n'y a qu'un format de sortie disponible, qui est du HTML que je qualifierai de "classique" (comprendre, pas de DHTML et ajax dans tout les sens), avec une génération de code javascript pour la validation coté client. On peut ajouter d'autres formats, mais il faut modifier quelques lignes dans le code même de jForms, ce qui n'est pas des plus pratique, malgré l'existence d'une documentation sur ce sujet pour les "hackers".
Ce temps est cependant révolu : je viens de passer deux petites heures à modifier légèrement jForms afin que les générateurs de sortie soient sous forme de plugins. Ainsi, plus besoin de modifier le code de jForms pour ajouter un nouveau format. Il suffit de faire une simple classe que l'on dépose dans un répertoire de plugin, de faire les plugins de templates qui vont avec et c'est tout. Bien entendu, rien ne change au niveau utilisation ;-)
Il est probable ainsi que l'on puisse, dans Jelix 1.1, générer un formulaire HTML utilisant extjs par ex, ou générer un formulaire en XUL (et plus tard un plugin pour générer un formulaire HTML5 ;-) .
Prochaines évolutions dans jforms : de belles balises comme <htmleditor>, <captcha>.. ;-)
Commentaires
Encore du très très beau boulot laurent ! J'ai hâte d'essayer ça :)
Le choix d'une bibliothèque Javascript à intégrer à Jelix pencherait-il vers extjs ? :)
@benletibétain : non justement. Maintenant qu'il y a la possibilité de faire son propre "builder" dans jForms, on pourra choisir sa propre lib JS pour faire des formulaires, en faisant son propre builder ;-)
Ce que je pense faire en fait, et pour éviter que l'archive de jelix soit énorme, c'est d'intégrer les contributions des "builders" (sur extjs, Yahou UI etc,), mais de ne pas intégrer les libs JS en elle-même. Par exemple, si tu veux faire du extjs, y aura tout dans le code Jelix même, mais il faudra aller te cherche la lib JS sur le site de extjs.
Bon maintenant, cette décision de ne pas intégrer le JS n'est pas définitive. Faut que je vois le volume de fichiers que cela peut représenter.
En tout cas, je ne veux pas imposer une lib js précise, et je ferais tout ce qu'il est possible de faire pour que les API de jelix soit suffisement souple pour choisir ce que l'on veut utiliser coté client.
Bonjour,
pourquoi ne pas utiliser XSL pour gérer les templates ?
@nico : bouahahah, XSL !! Qu'est ce qu'il ne faut pas entendre... :-) Certainement la pire invention au W3C...
"Certainement la pire invention au W3C..." Rien comparé au W3C XML Schema
@quode : ah oui, je l'ai oublié celui là :-) Un bon candidat pour le concours du pire. Mais pour moi, XSL est quand même pire que XML Schema...
C'est que tu connais mal XML Schema (et XSL). Par contre, t'es un bon troll ;-)
@fabrice : non, ce n'est pas un troll. Quand on compare RelaxNG à XML Schema, y a pas photo, RNG est largement plus simple à écrire. Quand on compare STTS à XSLT, là aussi STTS est beaucoup plus simple surtout quand on connait déjà CSS (bon ok, STTS n'est pas aussi puissant que XSL, mais suffirait largement à 90% des besoins).
Laurent, je ne comparais pas XML Schema à d'autres langages de schéma (c'est trop facile, y'a pas pire); je rebondissais simplement sur ton "XSL est quand même pire que XML Schema".