Si vous avez déjà touché à Zend Framework, vous vous êtes peut-être déjà pris la tête sur ses formulaires.
Et dans ce cas la, vous comprenez déjà probablement ce que je veux dire avec ce titre. Sinon, la suite détaille.
Voici un exemple de formulaire un petit peu complexe.
Vous pouvez en voir le résultat sur la page de gestion des mots clés de RefStats.
Comme vous pouvez le constater, il est assez difficile de comprendre l’intérêt d’un tel formulaire, ce qu’il affichera et même les champs qu’il contient.
Le problème des formulaires ZF est le même que dans beaucoup d’autres composants du framework : ils veulent trop en faire.
Le but d’un formulaire côté serveur est pourtant simple : faciliter la validation des données.
Que cela soit dans Rails ou ceux-ci sont directement inclus dans les modèles ou dans Django et Symfony ou ceux-ci ne servent que à faire la validation, à chaque fois, les formulaires ne génèrent pas d’HTML automatiquement.
C’est, malheureusement, ce qu’essaye de faire Zend Framework.
Mais cela rends la chose illisible car pas ergonomique; impossible à modifier pour la première raison.
Et surtout, absolument pas DRY. Si vous avez besoin de placer deux fois le même formulaire pour les mêmes données. Mais les afficher différemment ou simplement ne pas permettre la modification de certaines données, il vous faut créer deux formulaires différents !
Alors qu’il serait tellement plus simple de ne faire qu’un seul formulaire mais deux pages HTML affichant celui-ci.
Du coup comme vous l’avez deviné, je ne vous conseille absolument pas d’utiliser ces formulaires.
Après, au niveau alternatives, je vous épargnerai Rails et Django. Tout autant que Symfony, qui requiert l’inclusion complète du framework.
En revanche Loic me souffle sur Twitter que JForms serait pas mal.
Mais il est l’un des développeurs du framework et je n’ai pas eu l’occasion de tester la chose. Donc vous êtes sans filet !
Je crois que c’est justement tout l’intérêt de Symfony 1.2, chaque composant est indépendant, il est donc tout à fait possible de n’utiliser que le framework de formulaire de Symfony, mais à vérifier !
+1 pour ZFForm sinon, l’utiliser c’est pain in the ass sur de gros formulaires, rien que les decorateurs, ya de quoi devenir fou :/
Tout a fait d’accords, je serais d’avis de faire comme toi : le formulaire ne gere que la validation des données, affichage des errors, envoie du post mais n’affiche pas du HTML.
Pour les helpers HTML ok mais pas pour les formulaires.
Faudrais avoir le temps de le développé
Je n’ai pas saisie ton point négatif sur le fait de réutiliser le même formulaire sur les même données. Rien ne t’empêche de cloner ton formulaire et de le modifier comme bon il te semblera, non ?
@Joris oui, mais faire du copier/coller c’est pas DRY : tu répète du code inutilement, rendant la chose plus difficile à mettre à jour par la suite.
Très bonnes remarques, j’avais beaucoup apprécié sur mes premiers formulaires l’aspect intégralement généré (validation + rendu HTML), surtout si l’on a des comportements graphiques génériques et répétitifs par exemple dans un backend. Mais effectivement, rapidement, on se rend compte de la limite de ce système et on se sent vite enfermé.
Quant à sfForm de Symfony 1.2, il est utilisable en tant que framework sans embarquer tout Symfony, en voici un exemple :
http://jeremybarthe.com/fr/php/sf-form-de-symfony-en-tant-que-framework
Je suis d’accord sur le fait que la gestion des formulaires avec le ZF est assez perturbante au départ mais le problème est que tu attrapes une paire de ciseaux par les lames et blâme le concepteur de l’outil.
Ton approche est celle de base sur les formulaire mais elle ne convient qu’aux formulaires simples. Pour des choses plus complexes, les décorateurs sont une horreur, j’en convient.
Dans ce cas, il vaut mieux utiliser une vue en y plaçant manuellement les éléments de ton formulaire.
Ce qui règle également ton second point concernant le principe DRY.
L’approche du ZF sur les formulaires reste Objet avant tout.
C’est pour cette raison que tout ce qui est manipulable sur un formulaire ZF reste un Objet.
Personnellement je ne suis pas d’accord sur le problème du principe DRY puisque tu peux très bien créer tes propres décorateurs réutilisables qui utilisent tes propres helpers pour le rendu. Pour la réutilisation globale d’un formulaire, tu peux (comme j’ai l’habitude de le faire) envoyer des paramètres dans le constructeur de ton formulaire qui font que ton formulaire est différent selon certains paramètres.
Après j’avoue une chose : la prise en main n’est pas facile. Mais c’est comme tout, il faut de l’entrainement. Si on veut être un maître dans le maniment de l’épée, il faut certes une bonne épée, mais aussi un bon entraînement
De plus, pour la lisibilité de formulaire, j’utilise plus souvent la notation par tableau comme base.
Ex: (j’espère que le [ code ] passe…)
'div', 'class'=>'group')) ); $configForm = array( 'action' => Zend_Controller_Front::getInstance()->getRequest()->getRequestUri(), 'method' => 'post', 'elementPrefixPath' => array( 'validate' => array( 'prefix' => "Rx_Validate", 'path' => "Rx/Validate/" ) ), 'decorators' => array( 'FormElements', array('HtmlTag', array('tag' => 'div')), 'Form', ), 'elements' => array( 'login_email' => array('text', array( 'label' => 'user.email', 'validators' => array('EmailAddress', 'EmailExists'), 'required' => true, 'decorators' => $inputTxtDecorator, 'class' => 'iconised email' )), 'login_pwd' => array('password', array( 'label' => 'user.pwd', 'required' => true, 'decorators' => $inputTxtDecorator, 'class' => 'text' )), 'login_rememberMe' => array('checkbox', array( 'label' => 'user.rememberMe', 'filters' => array('Int'), 'decorators' => array( 'Label', 'ViewHelper', array('HtmlTag', array('tag' => 'div', 'class'=>'group rememberMe')) ) )), 'connectValid' => array('submit', array( 'label' => 'validate', 'class' => 'submit', 'decorators' => array( 'ViewHelper', ) )) ) ); parent::__construct($configForm); // pourquoi ne pas éditer ici le form en fonction d'autres paramètres... ?! if (isset($options['rajouteUnChampPourTesterRobot'])) { //... $this->addElement(....); //... } } }J’en ai des beaucoup plus complexe qui restent tout aussi lisible. Je trouve que les possibilités des Zend_Form sont très plaisantes. C’est pour cette raison je vous conseille grandement l’utilisation de ces formulaires !
Oula le code à complètement merder avec la balise < php …
@Mr.MoOx je suis persuadé que très bien maitrisés les formulaires ZF sont une merveille.
Cependant ils demandent un temps d’apprentissage tellement long que 70% des développeurs passent à autre chose de dépit.
C’est bien dommage !
Qu’es ce que je gagne comme temps aujourd’hui ! :p
Je ne me vois même plus faire un formulaire à l’ancienne, je crois que je sais plus comment on fais
C’est bien dommage. Tu sera bien emêté le jour ou, pour une raison x ou y, tu ne pourra pas utiliser ZF. Il n’y a pas que PHP dans la vie (heureusement !)
Oui y’a aussi Javascript et jQuery (blague)
Vous dites presque tous que ça demande de l’apprentissage, le problème que je rencontre est le manque cruel de tutoriels explicites…
Qui peut le plus peut le moins !
Damien, rien ne t’emepêche de n’utiliser que les fonctions de validation et de gestion des erreurs de tes objets Zend_Form, et de desactiver les Decorators par défaut.
Pour la lisibilité du formulaire, je préfère utiliser la syntaxe suivante pour ajouter des élèments :
$this->addElement(’select’, ‘idType’, array(
‘label’ => ‘Type de societe’,
‘validators’ => array(‘NotEmpty’),
‘multiOption => array(….)
));
(je ne pense pas que l’indentation va passer correctement dans le commentaire, mais en indentant correctement ta hiérarchie de tableaux, c’est vraiment très clair)
En ce qui concerne le problème de rendu du formulaire, j’ai l’habitude de transformer mes objets Zenf_Form en tableau d’élèments (grâce à une méthode toArray()), avant de les passer à ma vue Smarty. Je récupère ainsi dans ma vue seulement les données destinées à être affichées.
Il m’est ensuite très facile de placer mes éléments et mes messages d’erreurs à la main, où je veux dans mon template, et même, avoir plusieurs templates pour rendre mon formulaire differemment.
Tout à fait d’accord avec Jean-Marc, plutôt que de décorer un formulaire trop complexe, l’usage d’une vue pour le rendu du formulaire permet de faire de belles choses très simplement.
Il faut un tout petit peu d’apprentissage, mais franchement, ca vient très vite si on est à l’aise en PHP5 et en dev web en général.
Ca permet tout de même de mutualiser une partie du balisage. Une fois que le travail est fait, tout est ok !
Je me sers même de mon objet Zend_Form pour pré-valider mon formulaire via ajax
Alors pour répondre à tous ces commentaires, je suis bien conscient que, une fois qu’on les maitrise bien et qu’on a passé plusieurs à bosser dessus, c’est cool.
Mais pas quand on bosse avec ZF une fois tous les 3 mois on peut pas passer son temps à redécouvrir les forms.
C’est quelque chose d’assez récurrent sur le ZF. Ils font des choses très bien.
Mais qui sont très loin d’être KISS (Keep It Simple, Stupid)
L’héritage sur les formulaires ca marche aussi, et les décorateurs ne sont pas obligatoires.
class Form_Article extends Zend_Form
{
public function init()
{
$this->addElement(‘text’, ‘titre’, array(
‘label’ => ‘Titre’,
‘required’ => true,
‘filters’ => array(‘StringTrim’),
));
Aucune notion de décorateurs, et l’affichage se fait dans une vue :
<form action="url(array(« controller » => « identification »), null, true)?> » method= »post »>
formIdentification->email->getLabel()?>
formIdentification->email->renderViewHelper()?>
formIdentification->email->renderErrors()?>
formIdentification->motDePasse->getLabel()?>
formIdentification->motDePasse->renderViewHelper()?>
formIdentification->motDePasse->renderErrors()?>
formIdentification->submit->setAttrib(« class », « lancer »);
echo $this->formIdentification->submit->renderViewHelper();
?>
Toujours mon précédent commentaire hein.