Discussion :

[Community Management]

Bonjour,

N'hésitez pas à poster à la suite les "meilleures pratiques" (best practices) avec Zend Framework.
Par exemple : comment implémentez-vous les formulaires, à l'aide de classes (héritage) ou bien de helpers ?

[Janitrix]

J'avoue que le traitement de formulaire m'a toujours semblé problématique, je serais intéresser par vos expériences.

D'ailleurs, que penses-tu Yogui de l'exemple de Rob Allen dans le tutoriel que tu as traduit ? Est-ce là une bonne manière de faire selon toi ?

[Yogui]

D'ailleurs, que penses-tu Yogui de l'exemple de Rob Allen dans le tutoriel que tu as traduit ? Est-ce là une bonne manière de faire selon toi ?

Non, ce n'est clairement pas une solution idéale. Rappelle-toi que ce n'est qu'un tutoriel "premiers pas"

[Dia_FR]

salut
je débute sur ZF

pourrais-tu argumenter ton avis sur l'utilisation de classes pour créer un formulaire ?
pour moi à première vue ça me semble une méthode intéresante

si ce sujet a déjà été débattu je veux bien le lien
merci

[Janitrix]

Bon finalement j'ai opté pour l'héritage et j'en suis totalement satisfait. J'avais peur que cela ne fonctionne pas car je ne voulais pas utiliser les fonctionnalités Vues de Zend_Form et garder le contrôle sur le code HTML. Mais finalement, le compromis est tout à fait possible.

Maintenant, l'héritage me semble plus logique d'un helper d'un point de vue Orienté objet.

Si vous voulez un bout de code, ya pas de soucis.

[absolom]

salut!
Oui, Janitrix, ça serait très interessant de voir ton implémentation...

Merci

[littleman]

+1, je serai moi aussi très intéressé.

[Janitrix]

Alors je crée mon formulaire dans ma vue, normalement, en xHTML. Du côté PHP, je crée une classe pour chaque formulaire, qui étend Zend_Form, et je redéfinis l'ensemble des éléments du formulaire que je veux valider.

Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
<?php
 
/**
 * Ce fichier contient la classe Form_Membre_Add.
 *
 * @copyright  2008 Gabriel Malkas
 * @license    "New" BSD License
*/
 
/**
 * @see Inuitech_Form
 */
require_once 'Inuitech/Form.php';
 
/**
 * Formulaire permettant d'ajouter un membre.
 *
 * @copyright  2008 Gabriel Malkas
 * @license    "New" BSD License
 */
class Form_Membre_Add extends Inuitech_Form
{
 
    public function init()
    {
 
        // Le nom
        $nom = new Zend_Form_Element_Text('nom');
        $nom->setRequired(true)
            ->addValidator(new Zend_Validate_StringLength(2, 32))
            ->addValidator(new Zend_Validate_Alnum(true));
 
        // Le mot de passe
        $password = new Zend_Form_Element_Password('password');
        $password->setRequired(true)
                 ->addValidator(new Zend_Validate_StringLength(6));
 
        // Les éléments sont ajoutés au formulaire
        $this->addElement($nom)
             ->addElement($password);             
 
    }
 
}

Puis, dans le contrôleur gérant le formulaire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
// On crée une instance du formulaire
        $form = new Form_Membre_Add();
 
        if ($this->getRequest()->isPost()) {
 
            if ($form->isValid( $this->getRequest()->getPost() )) {
 
                try {
                    Membre::add($form->getValues());
                    $this->_redirect('/Administration');
                }catch (Zend_Db_Exception $e) {
                    $this->view->messages = array('DbError' => $e->getMessage());
                }               
 
            } else {
                $this->view->values = $form->getValues();
                $this->view->messages = $form->getMessages();
            }
 
        }
 
        // On affiche la vue
        echo $this->view->render('administration/index.tpl');

Je ne suis pas certain que ce soit la meilleure manière de faire mais elle me satisfait pour le moment.

Si vous voulez des éclaircissements n'hésitez pas

[Alshten]

C'est une méthode très intéressante surtout que personnellement j'ai toujours pas réussi à dompter les Decorators mais l'idée de créer deux fois le même formulaire (une fois en xHTML et une fois en Zend Form) me gène un peu.

Sinon je voulais savoir si certains utilisaient Zend Cache ici et si oui, comment ? Je me demande s'il vaut mieux mettre en cache juste quelques résultats de requête ou des pages entières.

[Eusebe]

Sinon je voulais savoir si certains utilisaient Zend Cache ici et si oui, comment ? Je me demande s'il vaut mieux mettre en cache juste quelques résultats de requête ou des pages entières.

Personnellement je n'ai jamais utilisé Zend_Cache (mais je ne gère pas non plus encore d'application basée sur le Zend Framework en production), mais je pense que pour savoir ce qu'il faut mettre en cache, il est préférable de commencer par étudier son application et évaluer les points de contention avec Zend_Db_Profiler (pour analyser le temps pris par les requêtes) et Zend_Log (pour le reste). Et suivant ces résultats (qui dépendent bien sûr de l'application), on peut choisir si la mise en cache des résultats d'une requête suffit ou s'il faut mettre en cache une page entière.

[oranocha]

Concernant les formulaires et la manière de l'utiliser avec Zend_Form, je dis +1 ! C'est également de cette manière que je travaille et je trouve cela très souple et très flexible ...

J'ai une question de bonne pratique pour laquelle je voudrai votre avis. Je vous expose mon cas :

J'ai un controller Devis, dans lequel j'ai une action "générer" qui a pour but de montrer à l'écran la prévisualisation d'un devis. Le but est de voir ce que donne le devis et si celui-ci est correct de le valider en cliquant sur un bouton en bas de page.

La validation doit provoquer la génération d'un PDF qui est la copie conforme de que j'ai à l'écran (j'utilise domPDF).

La manière dont je désirai m'y prendre est de faire passer le contenu de la page dans un flux, à la fin du flux stocker le tout dans une variable et afficher également à l'écran.

Ensuite, le bouton déclencherait l'utilisation de DOMPDF en li envoyant le contenu de la variable pour la génération du PDF.

Toutefois, je ne sais pas si il est "propre" de mettre tout se code de flux directement dans la vue ? Y-a-t-il une autre solution ? Une meilleure pratique ? Ou ma solution est-elle la bonne ?

Merci,
Olivier

[goodpz]

C'est un formulaire qui sert d'input au devis (si je comprends bien).
Je ne pense pas que l'idée d'embarquer dans la vue une sous partie de la vue elle même soit pertinente. Tout dépend de la taille des données aussi.

En fait, tu adoptes ce choix parce que tu n'es plus capable de générer le pdf après une action de prévisualisation ? (tu perds tes données POST) ?

A première vue (non, il n'y a pas de jeu de mots), j'essaierai de gérer ça avec une approche RESTful de base. La ressource c'est le devis. Tu peux l'avoir en html ou pdf. Il y a une action différente pour chaque représentation (mais elles peuvent partager des mécanismes communs). Les données sont envoyées à chaque fois à partir du formulaire, donc rien n'est envoyé en doublon. En revanche, la prévisualisation pourrait être faite de manière asynchrone (ajax) par exemple. Ca serait aussi sûrement plus simple pour modifier le devis si celui-ci ne convient pas à l'utilisateur.

[oranocha]

Bonjour,

En fait, voici le flux exact ... Tout se déroule dans le controlleur "Devis" :

1. L'action "index" propose une vue au surfeur dans laquelle il obtient un formulaire lui proposant de sélectionner un projet dans une liste déroulante, d'indiquer une référence pour ce devis et un taux horaire. Il valide ses choix.
2. Il est ensuite diriger vers l'action "generer" qui lui propose une version à l'écran de son devis. Il peut ainsi vérifier que tout est correct. En bas de l'écran, 2 liens lui sont proposés ; un lien pour confirmer le devis et un autre pour l'annuler. Si il annule le devis, retour au point 1. Si il décide de confirmer, il passe à l'étape suivante.
3. L'idée de cette troisième étape (gérée par l'action "genererpdf") est de sauver des infos de base relatives à ce devis dans une table ET aussi de générer un PDF qui est une copie de l'écran précédent, sans l'afficher à l'écran mais en le sauvant dans un répertoire adhoc. Cette action ("genererpdf") ne doit pas proposer de vue au client ... L'idée serait qu'une fois les actions effectués, il y ait un redirect vers l'étape 4.
4. Cette étape est gérée par l'action "voir" qui repropose au surfeur une version HTML de son devis
...

Mon problème se situe à l'étape 3. Pas de souci pour sauver les données dans la table, pas de problème non plus pour faire le redirect mais un problème pour le PDF en lui-même.

En fait, il y a tout de même un fichier de vue derrière cette étape 3 ("genererpdf.phtml") mais qui n'a comme objectif que de générer la page dans une variable $html, sans rien afficher à l'écran.

Mon problème survient quand il s'agit de récupérer les données enregistrées dans cette variable $html pour la refaire passer à mon controlleur qui aurait la charge de générer le PDF avec DOMPDF. Y a-t-il une solution ?

Merci,
Olivier

[goodpz]

Ok. Je pensais que le pdf était pour le client. Et bien j'ai l'impression que tu peux utiliser Zend_Controller_Plugin_ActionStack qui permet d'exécuter plusieurs actions à la suite. D'abord générer le html (et gérer la db etc) et ensuite une autre action qui génère le pdf avec en paramètre le rendu de la première action. Tu aurais donc besoins de "flusher" le rendu avant la dernière action.
Pourquoi pas non plus un plugin en postDispatch (ou n'importe quoi qui te permette d'avoir la main sur le rendu).

Mais à la rigueur, ta "vue" n'est plus vraiment une vue en soi à ce stade, c'est juste des données pour générer le pdf. Donc tu dois avoir moyen d'instancier un Zend_View "local" et travailler avec son rendu directement dans l'action qui gère l'étape 3

[oranocha]

Salut goodpz,

Je suis d'accord avec toi quand tu dis que mon fichier "genererpdf.phtml" n'est pas une vue en soi car sa seule utilité est d'ouvrir un flux, d'y générer "une vue" et de stocker ce qui a été généré dans une variable $html.

Toutefois, malgré tes explications, je ne vois pas comment puis-je faire en sorte que cette variable $html (qui a donc été générée dans le script de vue et non pas dans le controlleur) puisse être ensuite traitée par le controlleur d'action ...

Tel est là mon souci ;-)

Encore merci,
Olivier