Zend FR

Regarde la :
http://wiip.fr/content/zend-form-config … -et-les-dd

c'est bien expliquer :p

de rien

Si ta suivis le tuto normalement tes balise DD et autres ave cle tutos ça te permet de les remplacer par les balise de tableau.

Par contre, il ne faut pas laissé les tag vide quand tu crées ton décorateur faut mettre une balise dedans soit des td tr th etc.... ou soit ce que tu veux <p> <span> <div> etc...

http://weierophinney.net/matthew/archiv … ually.html

Ha ben là effectivement ça a beaucoup plus de sens.

Merci Mikaelkael pour le lien. Apparemment ça répondrait précisément à ce que je cherche. Dommage que l'indexation Google ne l'ait pas fait ressortir en premier

Et comme tu dis iop974, je veux un truc tout nu : je crois qu'il ne faut pas tout mélanger. En l'occurrence, le mieux est l'ennemi du bien. je comprends volontiers ce qu'ont voulu faire les développeurs de Zend_Form, mais ils sont tombé dans l'excès inverse en oubliant un principe de programmation fondamental en POO : une classe ne doit faire qu'une seule chose, mais le faire parfaitement. Avec le couplage automatique et difficile à débarquer du décorateur, ils ont enfreint cette règle en rendant la classe capable de retourner un formulaire prêt à afficher, sauf que tous les développeur n'ont pas forcément besoin de ce type de structure en dl/dt/dd ou de tableaux html.

Par ailleurs, Julien Pauli lui-même him-self nous a dit alors que je suivais une formation Anaska Zend-Framework qu'il ne maitrisait pas le HTML en ajoutant plus ou moins que ça ne l'intéressait en fait pas vraiment. J'ai peur que ça ne reflète l'état d'esprit de beaucoup des développeurs du ZF : ils s'éclatent à plonger dans les profondeur de la programmation pointue en utilisant au mieux les meilleurs méthodes, les design patterns et autres bonnes pratiques, mais en se déconnectant de plus en plus de l'objectif final qui est, a toujours été et restera de faire du web.

Et justement, je voudrais rappeler qu'on fait du web. Que ce soit des sites publics ou de l'intranet de gestion, ça reste du web et donc du client/serveur qui dans la majorité des cas va aboutir dans un navigateur. Le code qui arrive là doit être standard et conforme. Ok, le dl/dt/dd est valide et conforme : et si je veux construire autrement ? Et encore je me limite au Zend_Form, je pourrais parler aussi de Zend_Db, j'en aurais pas mal à dire là dessus, mais ce serait hors sujet. Autant je n'ai jamais mis du tout le nez dans Symfony et j'avais depuis la première annonce du développement du ZF un à-priori favorable, autant avec le temps c'est devenu une énorme machine de plus en plus complexe et de moins en moins maniable, je commence à en revenir de plus en plus pour me tourner vers des solutions maison très largement moins lourdes.

Enfin bon, je vais mettre un petit moment en suspend ce que j'ai commencé à construire pour voir ce lien si c'est vraiment efficace.

Je n'ai pas encore réussi à trouver le temps de me plonger sérieusement sur Zend_Form mais j'avais jeté un coup d'œil au code des classes et il me semble bien qu'il y a bien les méthodes nécessaires pour récupérer la structure d'un formulaire et générer soit même le code HTML, non ?

Sinon je soutient à 100% Cyrano pour la conservation de la maitrise du code HTML au niveau de la vue, car un graphiste doit pouvoir lire ce code et le modifier sans l'aide d'un développeur.
De plus, si on compare la simplicité de l'HTML face au nombre de personnes sur ce forum qui ont des problèmes avec les décorateurs du Zend_Form, on se rend bien compte qu'il y a un problème de conception quelque part...

Ca dépend de ses besoins et contraintes.

Moi je pense qu'il y a une infinité de façon d'afficher un formulaire : outre les balises structurante table/ul/dl/p on peut, par exemple, vouloir ajouter du contenu avant ou après un champs de saisi particulier.
Je préfère donc laisser toute latitude à mon collègue graphiste pour faire les modifications qu'il veut sans qu'il est besoin de moi.

Heureusement dans un tutoriel que je vient de trouver - Decorators with Zend_Form - un exemple montre que l'on peut moduler le degré de dépendance entre le modèle et la vue :

<form action="<?= $this->escape($this->form->getAction() ?>"
      method="<?= $this->escape($this->form->getMethod() ?>">

<fieldset>
    <legend>Demographics</legend>
    <p>
        Please provide us the following information so we can know more about  you.
    </p>

    <?= $this->form->age ?>
    <?= $this->form->nationality ?>
    <?= $this->form->income ?>
</fieldset>

<?= $this->form->submit ?>
</form>

Je suppose qu'on doit pouvoir également personnaliser les champs de la même façon, par exemple pour pouvoir y définir une classe CSS sans modifier le code PHP.

Sur ce point Zend_Form me parait donc fidèle à l'esprit du ZF : on prend ce dont on à besoin et on l'utilise comme on veut.


Après l'utilisation des décorateurs semble déroutante pour pas mal de monde, mais pour avoir tenté à une époque d'écrire une librairie similaire je sais qu'il est difficile de ne pas arriver rapidement à une usine à gaz pour avoir une abstraction complète d'un code HTML pourtant simple de nature.

Dernière modification par OsoPardo (09-03-2010 17:30:52)

De toute façon, si on reste dans cette optique de séparation des roles, le code html se retrouve avec un objet $form avec lequel il peut faire ce qu'il veut
Rappel : il y a les View_Helper correspondants dans Zend/View/Helper/Form*

J'ai bien relu le tuto enfin de compte c'est la même méthode que mon lien a part qu'il mais tag à null soit tag = ""

Du coup ça créer un attribut tag dans la balise Label ... à null qui sert a rien....
Un truc serait de les mettre dans des span et appliqué ta mise en forme.... mais bon

Sinon le 2eme tuto de mikaelkael préconise de re définir carrément la class décorator :p en gros