Voyons un peu comment ça marche.

1) on créé un fichier XML décrivant les champs de saisie d'un formulaire. Pour l'instant la grammaire XML n'est pas totalement figée. J'essaie de faire un mix entre HTML et xforms. Le fichier pourra être généré via une instruction en ligne de commande, à partir des informations d'un dao ou directement d'une table.

2) À partir de ce fichier, jForms connait la structure du formulaire : types de champs de saisies et les contraintes. Il génère alors une classe PHP (à la volée et dans un cache) qui permet de gérer les données d'un formulaire : remplissage à partir d'un dao pour l'affichage, récupération des données reçus du navigateur et validation. L'API à utiliser dans les contrôleurs est alors relativement simple :

  • $form = jForms::create('sample', $recordId); pour créer une nouvelle instance d'un formulaire en session ($recordId n'est pas obligatoire si on n'a pas à gérer de multiples instances).
  • $form->initFromDao('madao'); pour initialiser son contenu à partir d'un dao
  • $form = jForms::get('sample'); pour récupérer une instance d'un formulaire
  • $form = jForms::fill('sample'); pour récupérer une instance d'un formulaire en le remplissant avec les données reçues du navigateur
  • $form->check() pour savoir si le contenu du formulaire est valide
  • $form->saveToDao('madao') pour sauvegarder les données d'un formulaire
  • jForms::destroy('sample'); pour détruire une instance d'un formulaire

C'est tout. Il y a bien sûr d'autres méthodes et fonctionnalités pour les gestions plus complexes de formulaires. L'api est suffisament souple pour faire des formulaires sur plusieurs pages, de réafficher un formulaire et son contenu où l'on veut, quand on veut etc...

Tout ceci est déjà dans la beta2. La beta3 contiendra ce qui suit..

3) Pour l'affichage d'un formulaire, il suffit de passer l'objet $form au template. Ex : $rep->body->assign('myForm',$form);, et ensuite d'utiliser les quelques fonctions de templates spécifiques :

{form $myForm,'sampleform_save'}
  <fieldset>
    <legend>Votre identité</legend>
          {formcontrols}
         <p>{ctrl_label}: {ctrl_control}</p>
         {/formcontrols}
  </fieldset>
  <p><input type="submit" value="ok" /></p>
 {/form}

formcontrols est en fait une boucle sur les champs de saisies, ctrl_label affiche le label d'un champs de saisie et ctrl_control le champs de saisie en lui même. On n'est pas obligé d'utiliser formcontrols et on peut alors utiliser ctrl_label et ctrl_control là où on veut en indiquant le nom du champs de saisie. Cela apporte ainsi une certaine souplesse. Tout est généré : la balise form, le code javascript de validation, les balises label et tout ce qu'il faut pour l'accessibilité etc...

Et pour les plus pressés, il y aura plus tard :

 {quickform $myForm,'sampleform_save'}

qui évite de faire tout ce qu'il y a dans l'exemple précédent (mais est moins souple forcément) :-)

4) Vous remarquerez qu'à aucun moment, si ce n'est lors de l'écriture du fichier xml, vous n'êtes obligés de manipuler explicitement les champs de saisies ou leurs données. Cela veut dire qu'un contrôleur ou un template peut être utilisé pour n'importe quel formulaire. Cela peut être trés sympatique pour un CMS qui permettrait à l'utilisateur de choisir un formulaire déjà créé pour sa nouvelle page, ou de créer[1] son formulaire via une interface ou alors le créer en écrivant le xml à la main (comme ce n'est pas du PHP, peu de risque de trous de sécurité). Le développeur du CMS n'a pas à faire un controleur pour chaque formulaire. Où même : Jelix proposera des contrôleurs génériques et des commandes en ligne de commande pour générer en un coup la gestion d'une table. Une interface type CRUD se fera alors en quelques secondes ! ;-)

5) Mais ce n'est pas tout : Jelix proposera à l'avenir d'autres plugins de templates, qui permettront de générer des formulaires autres que HTML : XUL, XForms etc.. (et ceci sans changer une ligne de code en dehors des templates, pour le développeur).

Notes

[1] Précision : dans ce cas, il n'est pas possible de reposer sur un dao. Ou alors cela peut être un systeme dans l'admin du cms qui permettrait au webmestre de rajouter des plugins au cms, qui contiendraient le script sql de creation de la table, le fichier dao et le fichier formulaire