Bonjour à tous,

J'ai quelques soucis avec jForm. J'ai besoin

• de pouvoir répéter des champs (décomposition en mouvement d'une opération) bug
• de gérer l'autocompletion sur champs bug
• de gérer la saisie par une popup avec l'utilisation de window.openDialog

J'ai essayé de modifier le code de jForm... ce n'est pas simple. Laurent a déjà créé un bug la dessus bug

Je me demande si la façon de faire suivante serait accepter par les cores développeurs:

• conserver la déclaration xml pour le formulaire
• virer le support de la version 1 du schéma xml des formulaires
• virer la gestion du multi-output
• générer le formulaire en html5
• utiliser une/des libs js pour combler les lacunes du navigateur (par exemple)

Je ne pense pas que jelix doit gérer les lacunes d'affichages du navigateur, javascript est là pour ça. Dans le cas où la fonctionnalité n'est pas traduite dans html l'ajouter en utilisant l'attribut data-*.

Vous en pensez quoi ?

A+

Salut,

J'ai essayé de modifier le code de jForm... ce n'est pas simple.

Oui, c'est vrai, et y a du boulot en plus de ça :)

conserver la déclaration xml pour le formulaire

oui.

Mais j'ai une autre idée d'évolution (pas encore creusée à fond): un jforms peut hériter d'un autre jforms. En pratique on aurait une methode sur jformsBase pour "importer" un autre formulaire. Et un nouvel attribut inherits sur <form>.

À ceci, ajouter le support de formulaire full php (une classe dans forms/), héritant obligatoirement de jFormsBase. Cela permettrait de faire des trucs en plus dans le constructeur ou autre, des trucs métiers etc, et en particulier, aussi, dans le constructeur d'ajouter les controles que l'on veut, voir même d'appeler la méthode d'import pour "heriter" d'un autre formulaire XML.

virer le support de la version 1 du schéma xml des formulaires

éventuellement, mais on peut aussi garder, si ça ne gène pas les évolutions.

virer la gestion du multi-output

virer le multi-output, à voir. c'est vrai que ça complexifie un peu le truc, et finalement, on ne l'utilise quasiement pas.

générer le formulaire en html5

builder html5, ça c'est assez facile sans changer quoique ce soit dans le core de jforms ;-)

Oui, un builder HTML 5 serai vraiment sympa couplé avec une réponse HTML 5 qui ajouterai un JS pour le support IE. Le builder, en fonction des navigateurs utiliserai soit la fonctionnalité HTML 5 soit un javascript équivalant.

S'il y a des gens intéressés je suis prêt à m'y plonger.

Ouaip, moi je suis intéressé par cette évolution. Même si je n'ai pas encore bossé dessus.

Par contre j'ai regardé plus en profondeur le code. Je pense que transférer le code d'affichage des controls depuis jFormsBuilder vers les jFormsControl devrait apporter énormément de clarté dans le code (par contre on perdrait la surcharge du builder). De façon plus global, je me dis qu'un jFormsControl devrait savoir se compiler et s'afficher... en gros un plugin. Le truc un peu compliquer sera de gérer les balises repeat/choice/...

Vous en pensez quoi ?

De façon plus global, je me dis qu'un jFormsControl devrait savoir se compiler et s'afficher

oui et non. L’intérêt d'avoir fait une telle séparation, c'est de respecter le MVC. Ce qui est implémenté dans le jFormControl, c'est la partie "Controleur", dans le compilateur, la partie "Model", et dans le builder, la partie "View".

Autre chose : mettre les trois partie dans une seul classe, alourdi l'appli au final : tu charges à chaque fois tout le code pour compiler même quand tu n'as pas pas besoin (c'est quasi du code mort puisque la compilation n'arrive qu'une fois de temps en temps, sur des centaines milliers de requêtes http). Le code de la vue, tu n'en a besoin que quand tu as besoin d'afficher.

si on retravaille les plugins jforms, il faudrait je pense implémenter plusieurs classes pour un même plugin, plutôt qu'une seule regroupant tout.

reste que ça me chagrine de supprimer le support d'autres formats que HTML5. Savoir qu'on puisse générer autre chose que du HTML, c'est assez sympa je trouve, assez proche de la philosophie MVC. Il faut soit trouver une solution, soit que je me fasse une raison :-)

J'ai relu le commentaire de ce bug. Laurentj y fait une objection sur l'intégration du parsing et du output au sein d'un plugin jFormControl car ça casse le pattern MVC (décomposition model = parsing / view = output). AMHO, le pattern MVC a un intérêt si on permet de gérer plusieurs vues (XUL, HTML, HTML5, xForm, ...). Je pense que jelix ne fera que du web et du HTML5, donc pour moi on peut dropper le MVC.
Dites moi si je suis surement trop extrême :D

Concernant le "formulaire full php", c'est une super idée. L'héritage de formulaire apporte pas mal de chose. Je me demande même si la compilation du XML pourrait créer cette classe. ça apporterai une homogénéité à jForm.

Je pense que jelix ne fera que du web et du HTML5,

XForms, c'est du web, HTML4, c'est du web. De plus, ce que fait une appli jelix, ce n'est pas forcément renvoyer du contenu à un navigateur, mais aussi offrir des services webs, des outils en ligne de commande. Bref, supporter d'autres types de markup que HTML5 peut avoir son utilité, même si moins courant, je te l'accorde.

Je me demande même si la compilation du XML pourrait créer cette classe

Je ne pense pas que ce soit une bonne chose. Si cela génère une classe dans ton module, cela veut dire que tu peux la modifier, et donc tu ne pourrais plus la régénérer. Du coup le XML ne servirait à rien. Or, je veux pouvoir me baser sur du XML, pour les IDE, la facilité de lecture, la génération de formulaire par les applis etc...

Effectivement, HTML5 ce n'est pas tout. Par contre j'avoue que je bloque sur comment rendre plus facilement modifiable jForm.

Typiquement créer un input de type autocomplete c'est complexe. C'est un cas de figure qui rentre pas pour moi dans l'architecture actuelle. Pareil pour le repeat.

J'aimerai pouvoir créer un plugin par contrôle. Genre,

• un plugin pour le parsing
• un plugin pour le contrôleur du contrôle :)
• un plugin pour le output (un repertoire HTML, HTML5, xForm, ....)

Pour le template, il est super simple d'ajouter des modifiers dans l'application. J'aimerai avoir la même simplicité pour les contrôles d'un formulaire (genre un input qui valide un code SIREN ou un slider en SVG super sexy... :) )

J'ai oublié dans la liste des formats supportés, des "dérivés" de HTML. genre, on veut faire des formulaires qui reposent complètement sur des lib javascript comme extjs ou autre.. Il faut alors générer du HTML/JS totalement différent.

Bon sinon, j'ai reflechi à une solution. Tout à base de plugin donc. Pour implémenter un champs de A à Z :

• faire un premier plugin qui contient deux fichiers définissant chacun une classe : l'une dérivant de jFormsControl, pour la partie contrôleur. Ça ne change donc pas par rapport à ce qui existe déjà. Une deuxième classe pour la partie compilation : elle est chargé d'analyser le XML d'une balise et de générer du code, comme ce que l'on trouve dans jFormsCompiler_jf_1*... Elle devra dérivé d'une classe de base contenant des méthodes utilitaires. à moins qu'elle doit accepter une classe principale jFormsCompiler_jf_1* contenant ces méthodes utilitaires. à voir.

J'hésite aussi sur le format XML. Est ce que chaque element de champs correspond à un plugin via le nom de l'element (Solution A), ou est ce que l'on a des plugins "natifs" (les controles actuels), avec leur propre tag, et pour les plugins, un tag plus générique comme <plugin type="foo">. (solution B)

J'hésite, à cause de la validation (et donc la complétion auto dans les éditeurs). Il faut pouvoir fournir un schema xml pour la validation. Mais à priori, faut que le schema soit connu à l'avance. ce qui n'est pas possible avec la solution A. (il y a peut être des solutions mais j'ai peur que ce soit compliqué à utiliser).

Ce plugin serait stocké dans plugins/formscontrol/foo

• Faire un deuxième plugin chargé de "builder" un controle. Il implémente au moins deux methodes, outputContent et outputJs, comme ce que l'on trouve dans le builder html actuel.

Ce plugin serait stocké dans plugins/formsbuilder/html/foo. si on avait des builders pour extjs, il faudrait le mettre dans plugins/formsbuilder/extjs/foo

Le souci avec des classes de builders pour chaque contrôle : les perfs vont être moins bonnes que l'implémentation actuelle, où tout est dans un unique fichier et classe...

à moins de faire un compilateur qui va générer une classe builder qui ressemblerait à jFormsBuilderHtml, pour chaque type de formulaire. Le plugin builder d'un champs se chargerait de générer le code PHP qui génèrera le code HTML. Mais ça risque de commencer à devenir super compliqué au niveau code :-)