Je cite un précédent thread:

À noter que jForms n'est pas tout à fait terminé (entre autre j'aimerai >ajouter la génération de formulaire HTML ou autre à partir d'un jform)

J'ai commencé à me balader dans le source pour essayer de voir comment ça pourrait être fait (je suis sûr que tu en as une très bonne idée). D'après ce que j'ai compris du source, ça prendrait place dans les classes héritant de jFormsControl. Disons qu'elles implémentent toutes une méthode asHtmlTemplateForm et une autre asHtmlTemplate qui renvoient les bouts de templates correspondant au contrôle. Ce qui me gêne est que le jFormsControl::datatype est systématiquement de type string. Il faudrait à tout le moins supporter les différents types de données présents dans les daos, voire laisser la possiblité d'en définir des propores à l'utlisateur.

Je présume que tu as des plans, si on peut t'aider à avancer dans leur réalisation, ça nous rendrait bien service en même temps.

Encore une question concernant les types de données, qu'en est-il des enums ? Ils ne sont apparemment pas supportés dans les daos, est-ce que ça fait partie de tes plans d'ajouter quelque-chose au alors faut-il que nous cherchioons tous seuls ?

tout ce qui concerne la génération, et les datatypes : ce n'est pas vraiment terminé en effet.

Pour la génération : je ne pense pas que je mettrais dans les classes controls les méthodes qui fournissent le html correspondant au controle. Pour la simple et bonne raison que je ne veux pas forcément générer du html.

J'avais donc dans l'idée que ce soit des plugins de templates qui le fasse, en particulier le plugin jform_field (voir /articles/drafts/forms ). Si on utilise jformhtml, on aura du html, si c'est jformxul, ce sera du xul etc...

Pour les enums : pas pris en compte effectivement. Mais y a til vraiment un interet ? je veux dire, ce qu'on récupère d'un champs enum, c'est un entier non ? donc type="integer" devrait suffire ?

Pour les datatypes : je compte uniformiser les datatypes de jform et celui des daos (au niveau des noms au moins, peut etre que jDao utilisera par la suite les objets datatypes pour les vérifications de valeurs)

Je regarderai tout ça de près. Concernant les enums, c'est au moins intéressant pour la génération automatique de formulaires, ça permet de générer des combo box au lieu de simples champs textes. Même chose pour les sets.

si je ne dis pas de bêtise, les enum et set sont définis lors de la création de la table. Comment alors en récupérer la liste ?

Avec la requête SHOW COLUMNS FROM (cf. http://dev.mysql.com/doc/refman/5.1/en/s(..) . Il faudrait que je vérifie si c'est du SQL standard, mais ça fonctionne avec mySQL.

 $result = mysql_query("SHOW COLUMNS FROM [table_name]");
 while($row = mysql_fetch_object($result)){
   if(ereg(('set|enum'), $row->Type)){
        eval(ereg_replace('set|enum', '$'.$row->Field.' = array', $row->Type).';');
    }
 }

On pourrait d'ailleurs imaginer générer des daos directement à partir du résultat de ces requêtes; puisqu'on récupère un object assez complet. Je crois d'ailleurs que c'est ce que fait Ruby on Rails.

Il y a un alternative, c'est l'appel direct de la fonction mysql_fetch_field

Enfin, bref, le but du jeu c'est d'utiliser les facultés d'introspection des bases de données pour n'écrire les choses qu'une seule fois, la référence étant la base. Une fois tous les fichier xml générés, on peut les augmenter des données complémentaires (pourquoi pas avec des overlay à la XUL ? ): ajouter des méthodes aux factories, spécifier une méthode de check de formulaire différente de celle par défaut, etc. Si la strucutre de la bd change ajout/suppression de champ; modifiaction de type, ou que sais-je encore, on regénère tout le bousin et on garde ses overlays.

Bon, là je me suis laissé emporté, juste les enums et les sets, ce serait pas mal déjà ;)

non je ne pense pas que je vais prendre en charge ça...

ça va être trop couteux. Il va aussi falloir trouver les équivalences dans les autres bases. Et surtout, je ne veux pas créer de dépendance entre jform et les daos.

Enfin bon, je verrais ça plus tard... À moins que tu te penches sur le problème et que tu proposes un patch.

Ca doit pouvoir se faire (un patch) . C'est surtout la gestion des types qui me chiffone pour l'instant, notemment les enum et les sets. J'en ai pas mal et ça m'embête de copier les décarations dans le template, je préfèrerais l'avoir dans la dao et/ou le formulaire; ou les récupérer depuis la DB à la volée (performances ?).

A ce propos, j'ai vu que tu avais des classes select et select1 dans tes controles de formulaire, à quoi sont-elles destinées ?

Un autre possibilité est que je remplace mes enums par une clé étrangère, mais la souplesse que j'y gagne ne m'apporte pas grand chose, je ne veux pas que ces valeurs puissent être modifiées par les utilisateurs.

j'ai vu que tu avais des classes select et select1 dans tes controles de formulaire, à quoi sont-elles destinées ?

cf terminologie XForms : select = selection multiple, select1=selection unique.

je ne veux pas que ces valeurs puissent être modifiées par les utilisateurs.

Je ne vois pas le rapport. Tu peux trés bien avoir des tables de référence que les utilisateurs ne modifient pas. Suffit de ne pas proposer la fonctionnalité ou les droits sur la table en question..

Ok, je viens de lire ça: http://www.w3.org/MarkUp/Forms/2003/xfor(..) en diagonale, je crois avoir à peu près compris l'esprit de la chose. J'essaye de comprendre un pu la portée du truc, on peut peut-être servir le formulaire XForm tel quel et faire le rendu HTML avec FormFaces ou AJAXForms. Il me semblait cependant que tu n'utilisais qu'un sous ensemble de xfomrs, est-ce que ça marchera quand même ? Par pure curiosité, qu'as tu enlevé ?

Sinon, select et select1 fonctionnent-ils ?

Pour le point 2, tu as raison, aucun rapport; les mots importants étaient

la souplesse que j'y gagne ne m'apporte pas grand chose

Ce qui veut à peu près dire: c'est mieux, mais je m'en fous que ça soit mieux. (Et ça corrige mon problème au passage). Je vais explorer un peu cette voie.