Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour à tous,
Après quelques utilisations de Zend Form et la lecture de certains posts sur ce forum, j'en viens à me poser la question de la bonne utilisation de ce composant.
Je l'ai utilisé dans quelques projets, mais mon but étant de l'afficher avec un simple echo $this->form je suis vite tomber sur quelques problématiques :
1) Comment insérer du code HTML dans mes formulaire (besoin d'un lien entre 2 champs texte, d'une image, ...)
-> Je l'ai résolu en utilisant ce décorateur : http://wiip.fr/content/un-decorator-pou … rm_element
2) Afficher mes formulaires sous forme de tableaux sauf 2 boutons (retour et annuler)
-> j'ai résolu ce problème à l'aide des options des décorateurs permettant d'afficher que la balise ouvrant ou fermante.
Au final, mes formulaires fonctionnent mais ils restent complexes à lire / maintenir, etc...
En parcourant ce forum aujourd'hui, j'ai vu que d'autres solutions étaient peut être possible (Zend_Form_Decorator_Description en lui spécifiant un tag opour le HTML, displayGroup pour les 2 boutons, ...) mais je ne les ai pas testés.
Mais si l'on regarde la logique, Zend Form ne devrait s'occuper que des champs de formulaires, pas de la présentation.
Aujourd'hui je me pose donc la question : Quelle meilleure solution ?
1) Afficher mes éléments de formulaires 1 par 1 genre :
<form id=<php echo $this->form->getName() ?>/> <div ....> <?php echo $this->form->getElement('truc') ?> </div> ... </form>
(C'est dans l'idée, je n'ai pas vérifié la syntaxe).
Cette solution me semble être une bonne solution dans le sens ou on garde la partie validation et éléments de formulaire à part de la partie présentation
2) Etendre le composant pour recréer complètement un composant maison qui fait ce que j'ai besoin ?
3) Ai-je mal compris l'utilisation de la bête ? Ai-je loupé des méthodes importantes, ...
Si certains veulent bien me faire un retour sur leurs expériences, mes idées, etc... ca serait cool.
Merci à tous
Hors ligne
Abandonne Zend_Form_Decorator .... conseil d'ami éclairé : Zend_Form_Decorator c'est LE composant qui te dégoutera de Zend Framework.
Solution 2 à privilégier en priorité.
Hors ligne
C'est vrai que c'est indigeste Zend_Form_Decorator mais c'est aussi "essentiel" au bon fonctionnement des formulaires. Faut comprendre comment les décorateurs s'imbriquent l'un dans l'autre et après ça va mieux. J'avais trouvé cet article qui m'a permis de mieux comprendre, si cela peut t'aider :
http://devzone.zend.com/article/3450
Hors ligne
Je dois avouer qu'au départ, Zend_Form_Decorator est très méchant mais quand on arrive à le dompter, il est un bon compagnon.
Au pire, dans des cas trop complexes, j'affiche comme tu dis mes éléments de formulaire individuellement. C'est une bonne alternative je trouves et le code à été conçus pour cela.
D'ailleurs, la façon rapide c'est comme ceci:
//Si on considère que tu as nommer ton élément truc <div ....> <?php echo $this->form->truc ?> </div>
Hors ligne
Les difficultés de Zend_Form viennent pour moi du fait que ce composant n'est pas clairement défini dans MVC
Zend_Form empiète sur le V et le C
à mon sens Zend_Form est avant tout un composant qui entre dans le scope du contrôle. il définit le mode de comportement que doit avoir un Formulaire. structurellement de quoi est-il fait comment le valide--t-on ? etc.
mais il déborde sur la vue pour donner un rendu du coup il est difficile de le maitriser.
si je m'en tient à sa raison de base d'exister (le contrôle) je devrait pouvoir le donner à une vue qui elle se chargerait du rendu par exemple en SVG mais on voit bien dans son implémentation que ce n'est pas aussi simple.
à mon avis on devrait avoir le package suivant
Zend +-From | +-Controller | +-Html | | +-Renderer | | +-Decorator | +-Svg | | +-Rendrerer | | +-Decorator | +-... | +-Rendrerer | +-Decorator +-XFrom +-Controller +-Html | +-Renderer | +-Decorator +-XFPlayer | +-Rendrerer | +-Decorator +-... +-Rendrerer +-Decorator
Zend_Form définit le formulaire structurellement parlant définition de l'action de la méthode de validation des champs association avec les objets métier (mapping form <-> objet métier)
le contrôleur donne l'objet métier à la vue.
la vue elle sait quel type de rendu elle fait Html svg etc. elle instancie un renderer approprié et le relie au formulaire pour généré la vue du formulaire.
il devient alors beaucoup plus simple de faire évoluer le tout.
rien n'empêche d'avoir un renderer dérivé propre à l'application qui prends en charge des spécificités
A+JYT
Hors ligne
Je suis d'accord avec le post précédent : l'article http://devzone.zend.com/article/3450 est le meilleur que j'ai lu sur le sujet.
Si nous atteignons les limites des décorators, il existe une piste que je n'ai pas encore explorée : rendre *individuellement* les champs dans une vue. L'article en parle.
Jean
Hors ligne
Bonjour, le Zend_Form est un composant très souple, tellement souple qu'il nous échappe parfois des mains !
Pour l'aspect MVC on peut générer un formulaire à partir d'un fichier XML, ce qui atténue un peu le problème.
http://blog.snakehit.be/2008/03/09/zend … -tutorial/
Pour insérer du code HTML on peut également utiliser un élément tel que celui ci:
<?php class Ma_Form_Element_Code extends Zend_Form_Element_Xhtml { /** * Default form view helper to use for rendering * @var string */ public $helper = 'formCode'; }
On utilise ensuite la méthode setValue:
$code = new Ma_Form_Element_Code("code") ; $code->setValue('<p>Ceci est du code HTML</p>'); $code->addDecorators(array( 'ViewHelper', array('HtmlTag', array('tag' => 'li')) ));
Zend_Form est difficile à mettre en oeuvre la première fois, mais les fois suivantes, l'écriture des formulaires se fait très rapidement.
Hors ligne
Bonjour,
Zend_Form est un peu particulier. Cela fait bientôt un an que j'utilise Zend dans des projets plus ou moins complexes (dont le dernier un CMS entièrement avec Zend, voir en pied de page).
Je n'ai certes pas l'expérience d'une personne certifiée Zend, mais je me suis rendu compte que le principal intérêt de Zend_Form est facilité le traitement des champs (isRequire, ...).
J'ai fini par arrêter son utilisation (pas totalement) pour une très bonne raison :
Les serveurs (apache, ...) interprètent plus facilement du code XHTML (pure) que s'il est généré en PHP. grossièrement (si je me rappelle bien de mes bases), le serveur va devoir interpréter plusieurs fois le même code pour rendre un rendu.
Ceci étant, ce que je dis est aussi contradictoire, puisque l'utilisation d'un système MVC implique que le rendu soit avant traité en PHP pour ensuite être rendu au visiteur.
Pour conclure, j'ai fait, il y a deux trois mois un petit test (afin de faire un choix) rapide des performances sur l'affichage entre le rendu d'un formulaire avec Zend_Form et un formulaire en XHTML (code à l'exacte identique et même fonctionnalité). Et bien qui est le grand gagnant ? (allé je vous le dis XHTML)
La différence n'était pas très importante, mais il y en avait une !
A l'heure actuelle, je préfère jouer sur la performance. Même si beaucoup ont l'adsl et qu'il est plus facile à afficher. Plus on en a plus on en ajoute !
Par contre, pour les codes redondant, Zend_Form reste très intéressant à utiliser.
Voilà mon petit retour d'expérience avec Zend_Form.
Bien cordialement.
PS: J'espère ne pas avoir fait faire des bonds aux inconditionnels de Zend_Form LOL.
Hors ligne
@nicko : tu devrais revoir un peu les tutoriels.
nicko a écrit:
Les serveurs (apache, ...) interprètent plus facilement du code XHTML (pure) que s'il est généré en PHP. grossièrement (si je me rappelle bien de mes bases), le serveur va devoir interpréter plusieurs fois le même code pour rendre un rendu.
Apache n'interprète rien du tout, il ne fait que traiter des requêtes. Si tu demandes un fichier PHP alors Apache (s'il est configuré pour) va le passer à l'interpréteur PHP, si tu demandes un fichier texte alors il retourne purement et simplement le texte.
C'est PHP qui va interpréter le code, et ensuite retourner au serveur Web un contenu.
nicko a écrit:
A l'heure actuelle, je préfère jouer sur la performance. Même si beaucoup ont l'adsl wink et qu'il est plus facile à afficher. Plus on en a plus on en ajoute !
Avoir ou non l'ADSL n'a strictement rien à voir. Que tu le fasses avec Zend ou à la main, le temps de transfert des données sera le même.
Ce qui change, ce sont le nombre instructions exécuter.
Il est plus rapide (c'est relatif hein) d'exécuter :
echo '<ul> <li>1</li> <li>2</li> <li>3</li> </ul>';
Que de faire
function echoLi($n) { echo '<li>'.$n.'</li>'; } echo '<ul>'; for ($i = 1; $i <= 3; $i++) { echoLi($i); } echo '</ul>';
Mais il est aussi plus rapide de modifier la façon de représenter les LI dans le second cas que dans le premier (mettre style="color: #FFF;" par exemple).
Il est parfois préférable de perdre quelques microsecondes à l'exécution du code que de perdre 1h à modifier du code.
Dernière modification par Blount (06-04-2010 14:19:13)
Hors ligne
Bonjour Blount,
Oui effectivement je me suis très mal expliqué
Lorsque je parle d'ADSL, je me doute bien que cela ne jouera en aucun cas sur le traitement les requêtes d'un serveur. Mais l'air du 56K n'est pas si loin que ça LOL.
Ensuite, bien sur que tout ne peut pas être mis en HTML et certaines portions de code doivent être factorisé afin d'améliorer la ré-utilisabilité.
C'est pour ça que j'ai dis :
Par contre, pour les codes redondant, Zend_Form reste très intéressant à utiliser.
Apache n'interprète rien du tout, il ne fait que traiter des requêtes. Si tu demandes un fichier PHP alors Apache (s'il est configuré pour) va le passer à l'interpréteur PHP, si tu demandes un fichier texte alors il retourne purement et simplement le texte.
C'est PHP qui va interpréter le code, et ensuite retourner au serveur Web un contenu.
Tu l'as dit plus clairement que moi, mais on ne trouve pas ça dans les tutos
Bien cordialement.
Hors ligne
Tu l'as dit plus clairement que moi, mais on ne trouve pas ça dans les tutos wink
C'est ce que je reproche le plus au tutoriel traitant de la programmation Web.
Ils ont tendance à trop raccourcir les choses pour mieux expliquer. Au final on pense avoir compris le fonctionnement d'un serveur, alors qu'il n'en est rien.
Par exemple, sur le Site du Zéro, tu trouves ceci en haut de tuto :
Pour utiliser PHP, il faut connaître au préalable les langages XHTML et CSS
En quoi le XHTML et le CSS empêcheraient l'utilisation de PHP ?
Attention, je respect ce que font les auteurs de ces tutoriels, c'est un travail qui demande beaucoup de temps et pas forcément simple. Il est toujours plus facile de critiquer que de faire
Quand on parle d'optimisation, il faut bien connaître le fonctionnement des serveurs (logiciels). Mais c'est des choses à acquérir avec le temps, et je suis d'ailleurs loin d'avoir touts en tête …
Dernière modification par Blount (06-04-2010 15:33:23)
Hors ligne
Mois, j'utilise à fond Zend_Form
Ca me permet de faire des choses comme
public function getUpdateForm(Doctrine_Record $netinfo, array $options = array()) { $form = $this->getAddForm(); // renvoie un Zend_form $form->addElement('hidden', 'id', array('decorators' => array('ViewHelper'))); $form->getElement('type')->setMultiOptions($options); $form->populate($netinfo->toArray()); return $form; }
Je n'ai qu'un seul formulaire pour 2 action (ajouter modifier), sans compter le code inutile pour remplir les champs value, et les boucles pour les options, ...
Et encore, c'est un exemple assez simple, mais j'ai des fois des conditions sur l'utilisation/déclarations de certains champs, etc...
Sans compter divers automatismes pratique ( filtrer, validation, erreurs, ...)
Le pattern décorator est globalement bien utilisé et fait son job. même si des petites modifs serait à revoir.
Hors ligne
il y a un très bon tutorial pour réaliser des forms avancées sans passer par les décorateurs : http://www.dator.fr/tutorial-creer-une- … tchmydesk/
Hors ligne
Bonjour à tous,
Merci pour vos retours. Ce que j'en conclue c'est que la majorité semble utiliser sans souci Zend Form à condition d'être allé un peu plus loin que moi dans son utilisation et d'utiliser correctement les décorateurs
Je pense donc que je vais déjà (re)lire les tuto filer ici et là, relire la doc, et voir ou cela me mène.
Dans un sens je suis rassuré. Va juste falloir que je trouve le temps.
Merci à tous en tout cas pour vos commentaires constructifs !
Si vous souhaitez en rajouter, n'hésitez pas.
Stoomm.
Hors ligne
J'espère que tu deviendras toi aussi un master Zend_Form !
N'hésite pas à faire beaucoup de lectures et à poser des questions. Je crois moi aussi que tu choisis la bonne voie.
Il y a un bon moment que j'ai gagné contre Zend_Form...mon dernier problème remonte quand même de loin avec ce module !
Hors ligne
Rebonjour à tous,
Je viens de lire ce fameux article devzone et le décorator ViewScript a particulièrement attiré mon attention.
Ce décorator peut être utilisé pour un élément ou pour 1 formulaire en entier (solution mise en place dans l'article). Il me semble que c'est ce dont parlait Jean.
Ce mode de fonctionnement rejoint assez ce dont je parlais en solution 1 sauf que cela permet ici d'avoir le template du formulaire à part donc un formulaire complètement réutilisable.
La doc Zend indique ceci : L'utilisation du décorateur ViewScript est recommandée dans les cas où vous souhaitez avoir un placement HTML très détaillé et très fin de vos éléments.
Quand je relis vos réponses, je me dis que ce mode de fonctionnement ne remets pas en cause votre analyse. Il utilise la puissance de Zend Form et on peut utiliser / créer ses décorateurs si nécessaire. Mais il permet d'avoir dans des scripts de vue propre au formulaire la partie présentation et l'aspect formulaire pure dans le script php.
De plus, je conçois que tout pourrait être fait directement dans la classe du formulaire en PHP à l'aide d'autres décorateurs (cf réponse de Zartan ou la solution que j'ai déjà mise en place) mais je pense que cela complexifie légèrement la maintenance du code.
Enfin, ce mode de fonctionnement n'enlève rien à la souplesse de Zend Form (cf réponse de nORKy).
Ça c'était mon analyse, et c'est vers cela que je pense me tourner, mais j'aimerais d'abord avoir vos avis la dessus. Etes vous d'accord ? Avantages / Inconvénients de ce procédé (hormis que cela créé 2 fichier pour 1 formulaire) ? etc...
Merci à tous,
Stoomm.
Dernière modification par Stoomm (09-04-2010 14:44:16)
Hors ligne
Pages: 1