Hey ,

En ce moment j'étudie la gestion des formulaires chez PEAR, ZF, Sf, et bien d'autre. J'aimerais savoir lesquels vous préférez, vous avez utilisé, pourquoi, qu'est-ce que vous leur reprochez etc.

J'aimerais vos avis avant de me lancer dans un gros support de formulaire.

Merci .

j'utilise symfony 1.0 et son système de formulaires. les plus :
_ des fonctions pour afficher les champs classiques de formulaires
_ la possibilité de récupérer les valeurs depuis un objet
_ la possibilité d'afficher les erreurs, avec un préfixe et un suffixe ( possibilité de mise en forme )
_ les validateurs de base, la validation via un fichier de config en yaml
_ la possibilité de définir une validation pour un formulaire soumis
_ la possibilité de créer des classes de validation simplement
_ des fonctions pour faire de l'ajax

les moins :
_ on doit créer le formulaire en entier en version 1.0 : rien pour créer très rapidement un formulaire depuis la définition d'une table ( changé en 1.1 )

voilà

j'ai utilisé PEAR QuickForm, pas assez évolué à mon gout, trop de choses à écrire (en PHP) pour valider un formulaire, du code html pas très beau.

A+

Pascal

Dans la génération de formulaires à la volée, il y a quelques petites choses qui me chagrinent, nottament au niveau de la mise en page dudit formulaire, car tout est mis en place selon un schéma défini préalablement établi, tandis qu'en générant le formulaire élément par élément, on peut maitriser l'emplacement non ?
Personnellement, j'utilise un framework home-made et je ne sais pas comment ca fonctionne chez les autres donc je ne peux pas être d'un avis très utile...
Mais je vais apporter mon point de vue tout de même en éspérant que ca puise t'être utile Ivan.

J'ai une class "form", qui gére les validations, une classe "input" qui est étendue par tous les éléments et qui comporte les régles de validation qui peuvent être réecrites en modifiant la dite fonction dans la classe qui étend "input"
Chaque élément héritant de input est ensuite déclaré dans l'instance de la classe "form" qui a l'appel de la fonction form::validate() va valider les elements du formulaire un a un selon les régles predeterminées.
Chaque instance des elements est transmis a la vue car les classes d'elements comportent une fonction printItem() et printLabel() qui permettent d'afficher respectivement l'element et le label de celui-ci.
Sachant que la validation se fait dans le controller et que la vue est appellée après le controlleur, une erreur est affichée automatiquement si nécéssaire.

Si tu veux Ivan, je t'enverrais les sources de ce que j'ai fait, car je crains de ne pas avoir été clair.

Si si c'est clair, enfin je comprends .

@pascalje : J'aime bien justement comme fait PEAR QuickForm car le code HTML ne se mélange pas au PHP. J'ai regardé du côté de Zend sinon. Comme d'habitude, ils ne savent rien faire en-dessous de 12 000 lignes de code, mais c'est tout de même intéressant.

@momox : Je continue mon explication ci-précédente. Tu te plains de la mise en page des formulaires générés automatiquement, mais ne penses-tu pas que si on utilise des décorateurs adaptés, ce ne serait pas plus sympa ? Une fois les décorateurs écris, on décrit notre structure via PHP, et on ne s'occupe plus des mises en forme et autre chose du genre. On se contente d'afficher nos formulaires, et c'est fini. Ça prend peut-être un peu de temps au début (mais pas tant que ça), pour en gagner pas mal par la suite.

@pascalje (bis) : pourquoi tu n'aimes pas PEAR QuickForm ? Tu me dis qu'il y a trop de code PHP à écrire, pourquoi cela est-il gênant ?

Merci .

je n'aime pas PEAR quickform à cause de cette validation verbeuse :
$form->addRule( /* ici plein de paramêtres */) * chaque régle de validation

symfony est pratique en centralisant toute la validation dans un fichier de config en yaml :
_ centralisé
_ lecture/écriture du yaml facile

je suis fan du yaml pour sa simplicité.

A+

Pascal

@pascaltje : J'ai regardé le yaml et il est vrai que c'est un language facilement lisible pour l'homme, sans syntaxe reberbative.
@HyWaN : Donc on en reviendrait à un template pour les formulaires qui définirait leur affichage ? Dans ce cas là je plussoie si c'est facilement personnalisable et je suis prêt à mettre la main à la pâte.
Après ce qu'il faut, c'est pouvoir gérer plusieurs templates dans ce cas là...
Petit exemple:
- http://moabraham.free.fr/progz/Capture.png
- http://moabraham.free.fr/progz/Capture-1.png
Deux formulaires différends avec mise en page différente, mais même système de validation.

Hey ,

Merci pour vos avis.

J'étais parti sur un code un brin verbeux mais comme l'a fait remarqué pascaltje, il est bon de pouvoir centraliser ces informations dans un fichier (XML, YAML, INI, etc.), et pas que la validation. J'ai donc laissé le choix : soit on utilise chaque objet manuellement, soit on utilise des tableaux. Avantage des tableaux : ils peuvent provenir d'un fichier YAML par exemple. Donc je reste dans ma philosophie de départ en proposant celle de pascaltje (qui est bonne aussi).

Merci, sujet résolu .