Discussion :

[Amon]

Après avoir écumé les rares tutoriaux MVC sur le sujet, je me retrouve un peu à sec.

Dans ce post, MaitrePylos utilise une librairie externe.
Dans cet exemple donc, comment donner au PdfController des données issues d'une table gérée par un autre Controller ?
Pour reprendre cet exemple que beaucoup connaissent, comment passer proprement à ma librairie PDF la liste des albums que j'ai dans ma base ?

La question se pose également lorsqu'une vue doit afficher des données en provenance de plusieurs controllers. (pour reprendre l'exemple des albums : afficher d'un côté le listing des albums, et de l'autre, le listing des artistes associés).

Merci d'avance pour vos retours avisés

[Eusebe]

Bonjour,

A mon sens, les tables ne doivent pas être gérées par des contrôleurs, mais par le modèle lui-même, qui doit en assurer la cohérence. Les contrôleurs ne doivent servir qu'à rassembler la bonne partie du modèle avec la bonne vue.

Dans cette optique, et toujours selon l'idée que je me suis faite de ce pattern, la génération d'un pdf n'est qu'une façon de présenter des données, et correspond à une vue. Pour l'exemple que tu prend (albums et artistes), on peut utiliser un même contrôleur, et même la même action pour présenter à la fois les données en HTML et en PDF. La différence se ferait alors par un simple paramètre. L'action, en fonction des paramètres passés, est alors à même de sélectionner et filtrer le modèle approprié, et utilise soit la vue HTML soit la vue PDF...

On peut alors tout à fait simplement multiplier les méthodes d'export des données, sans toucher au modèle, et très peu au contrôleur, en ajoutant d'autres vues (HTML pour affichage à l'écran, PDF pour l'impression, XML pour une application externe, etc...). Et il me semble que c'est bien là tout l'intérêt du pattern MVC .

[Amon]

Tout d'abord merci Eusebe pour ta réactivité

Ensuite je partage tout à fait cette vision théorique du pattern MVC. J'ai néanmoins beaucoup de mal à voir concrètement les répercussions sur mon code.

As-tu des exemples ? des ressources à partager ?

[MaitrePylos]

Pour les valeurs de ta db, tu fais comme dans l'exemple.

L'exemple fais ceci :

Code :

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

1
2
 
$this->view->albums = $album->fetchAll();

Rien ne t'empêche de faire pareil et de mettre les records dans une variable, personnellement je fais ceci :

Code :

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

1
2
3
4
 
$formData = $album->fetchAll();
 
My_Pdf_Fichier1::pdf($formData);

Tu auras compris que la génération de mon Pdf se trouve /library/My/Pdf/Fichier1.php

Dans ce fichier, je récupère les valeurs de la db, de la même façon que l'exemple.

Pour différentes vues, avec la même action il faut utiliser contextSwicth, regarde la doc paragraphe 10.8.4.3

[GrandFather]

Bonjour,

les contrôleurs ne constituent le squelette de l'application, et la divisent en blocs fonctionnels constitués d'action. Le code des contrôleurs doit être le plus concis possible et doit servir essentiellement de lien entre modèles et vues. En clair, il ne doit concerner que la remontée et la vérification des formulaires, appeler les méthodes des modèles et déclencher le rendu des vues. On peut également y adjoindre quelques vérifications liées aux ACL, et toutes autres actions spécifiques qui n'ont pas leur place dans les deux autres couches et qui ne justifient pas à elles seules une implémentation dans une classe dédiée.

La génération de documents PDF pose un problème particulier de positionnement dans un contexte MVC ; si on s'en tient à une définition formelle, un document PDF est une vue puisque faisant partie de l'IHM, mais concrètement sa production ne peut pas être implémentée comme celle d'une vue (X)HTML, c'est à dire par l'intermédiaire d'un template. Le moins mauvais choix, à mon avis, est encore de placer le code de production PDF dans une classe dédiée uniquement à cet usage et donc totalement distincte des contrôleurs, vues et modèles. La classe est instanciée à partir d'une méthode d'action, et la communication des données à y afficher peut se faire simplement en les passant comme paramètres de son constructeur.

[MaitrePylos]

Le moins mauvais choix, à mon avis, est encore de placer le code de production PDF dans une classe dédiée uniquement à cet usage et donc totalement distincte des contrôleurs, vues et modèles. La classe est instanciée à partir d'une méthode d'action, et la communication des données à y afficher peut se faire simplement en les passant comme paramètres de son constructeur.

...n'est-ce point mon exemple?...oui ça va,c'est mieux écrit

[oliviercuyp]

Bonjour tout le monde,

Je n'ai aucune expérience dans la création de pdf et je vais sans doute dire une bétise mais n'y a-t-il pas une classe spécifique de ZF pour ce problème : Zend_Pdf ?

[MaitrePylos]

Bonjour tout le monde,

Je n'ai aucune expérience dans la création de pdf et je vais sans doute dire une bétise mais n'y a-t-il pas une classe spécifique de ZF pour ce problème : Zend_Pdf ?

Oui, mais elle est très limité, comparé à PhpToPdf par exemple.