Zend FR

Coicatak · 21-03-2013 18:24:02

Salut,

J'ai un problème assez embêtant auquel je ne trouve pas de solution depuis ce matin... Alors voilà:

Je sais comment faire des requêtes SQL dans un contrôleur et les passer à une de ses vues. Seulement j'aimerais faire la même chose de façon globale avec le layout: c'est à dire passer des données au Layout à partir d'un "contrôleur global". Et je ne vois pas comment arriver à cela étant donné qu'un layout n'a pas de contrôleur (et que je débute en Zend).

J'ai trouvé comment passer des données au layout en ajoutant au Module.php le code suivant:

Code:

 
public function onBootstrap($e)
 {
        // You may not need to do this if you're doing it elsewhere in your
        // application
        $eventManager        = $e->getApplication()->getEventManager();
        $moduleRouteListener = new ModuleRouteListener();
        $moduleRouteListener->attach($eventManager);
        
        // Pass the needed variables to the Layout view
        $application = $e->getParam('application');        
        $viewModel = $application->getMvcEvent()->getViewModel();
        $viewModel->foo = "bar";
 }

Mais le problème c'est que dans Module.php je ne peux pas accéder à la base de données (du moins d'après ce que je sais).

Une autre solution serait d'utiliser les variables de session et de les passer dans le module.php mais je ne peux pas faire ça parce qu'il faut que la requête SQL soit appellée à chaque rechargement de n'importe quelle page utilisant le layout pour toujours avoir des données à jour.

Une solution?

Merci d'avance

Dernière modification par Coicatak (21-03-2013 18:25:14)

alien7 · 21-03-2013 19:39:14

Bonjour,

Tu peux utiliser des widgets.

Par bakura10 :
http://www.michaelgallego.fr/blog/2012/ … ar-widget/

jfvole · 21-03-2013 21:04:45

Bonsoir,

Pour ma part je dérive tous mes controller d'un même controller.

Code:

class FooController extends DefaultController

Ce controller parent est chargé entre autre de gérer le layout dans

Code:

class DefaultController extends AbstractActionController
{
public function dispatch(Request $request, Response $response = null)
    {
        $return = parent::dispatch($request, $response);
                 
                /// Traitement des requêtes lié au layout
        $layout->setVariable('Var',$var);
                ...
                
        return  $return;
    }
}

J'en profite aussi pour gérer les Roles ACL, l'authentification etc...

Dernière modification par jfvole (21-03-2013 21:05:37)

Coicatak · 23-03-2013 18:41:37

Merci à vous 2 pour vos réponses. J'ai trouvé ce que je voulais et même plus

Par contre, le controller par défaut où est-ce que tu vas le placer, dans quel dossier?

Dernière modification par Coicatak (23-03-2013 18:42:11)

Polzie · 24-03-2013 22:51:34

alien7 a écrit:
Bonjour,

Tu peux utiliser des widgets.

Par bakura10 :
http://www.michaelgallego.fr/blog/2012/ … ar-widget/

Voir de tels ramassis de conneries... Ca serait bien que les mecs montent un peu en compétence avant de faire des blogs de tutos en racontant 80% d'informations erronées. J'ai jeté un coup doeil a quelques tutos c'est vraiment ahurissant.

Orkin · 25-03-2013 00:00:45

C'est vrai que voir ce genre de réaction extrèmement constructif (il faut se l'avouer) de quelq'un qui n'a absoluement rien apporté sur ce forum et qui est totalement transparent et inconnu de la communauté du Zend Framework 2 ça renforce ta crédibilité. Si seulement tu apportais ne serait qu'un semblant d'explication technique qui permettrait d'affirmer ton commentaire ca aurait un semblant d'intéret. Bref c'est assez facile de cracher gratuitement sur les gens. Bakura reste un des principals contributeurs du ZF 2 et de mémoire un des principaux en France. Ceci dit au vu de ton savoir je t'encourage à contribuer activement au ZF 2 afin d'apprendre aux contribueurs reconnu la marche à suivre

Je t'encourage aussi à nous indiquer l'url de ton blog que l'on aille s'instruire. Merci d'avance pour nous tous

aromatix · 25-03-2013 01:42:45

de passage par ici, je me permet d'apporter quelques remarques :

le process de traitement d'une requête (pour faire simple) : initialisation et démarrage de l'application , chargement des modules, routage, dispatch (controller/action), rendu de la vue, envoie de la réponse

donc quand on en est au rendu de la vue ou layout, c'est juste un peu con de relancer une boucle de dispatch pour récupérer des données dans la base ( re-dispatch, un autre rendu de vue (resolver+renderer) avec des données depuis la base, que l'on injecte dans la layout)

l'article de Michael est sencé et une aide de vue est tout à fait logique pour ce besoin.
les acteurs clé dans le développement de ZF2 sont de cet avis aussi. leurs avis sur des méthode basée sur des aides d'actions comme action() et actionStack() , sont connus depuis longtemps .
un lien au hasard, où les commentateurs ne sont pas tous des inconnus : [url]http://www.rmauger.co.uk/2009/03/why-the-zend-framework-actionstack-is-evil/ [url]quelques arguments de ta part, polzie, sont les bien venus . et je serai ravi d'apprendre qu'on est pas mal à en avoir fumé de la bonne

Dernière modification par aromatix (25-03-2013 13:36:20)

bakura · 25-03-2013 08:34:23

Polzi > devant une telle attaque argumentée je ne peux qu'avoir tort ;-)...

Aromatix > sur ZF 1 la méthode par actionStack avait été déconseillé car actuonStack faisait justement ça : réinitialisation de l'application, routage, dispatch... Le concept était bon mais l'implementation de ZF était mauvaise.

Sur ZF 2 la méthode forward a été réécrite et ne fait plus toutes ces étapes et elle est bien plus efficace . Donc oui, forward ou aide de vue est la meilleure méthode est celle conseillée par la plupart des contributeurs.

Polzie · 25-03-2013 11:12:29

Ce n'est pas tant sur les solutions proposées telles que forward et des viewHelper que je m'indigne.
Je ne voulais pas entrer dans les détail, mais puisque vous insistez, okay, je vais argumenter en citant quelques passages du tutoriel.

"Heureusement, il existe une bien meilleure alternative sous Zend Framework 2 : les aides de vue".

Ravis d'apprendre que les aides de vue n'existaient pas dans ZF1. De plus, mettre du métier dans un viewHelper, discutable, même si ce n'est pas si mauvais en soit.

"De plus, tous les éventuels hooks qui pouvaient être ajoutés (par preDispatch ou postDispatch par exemple) étaient exécutés autant de fois que cette aide d’action était appelée, ce qui provoquait évidemment des effets de bords difficiles à débugger."

Totalement faux, les hooks de la boucle globale (controller plugins) ne sont effectuées qu'une seule fois. Seuls les hooks internes au dispatch, ceux des action helpers le sont, et c'est tout à fait logique et normal.

"une aide de vue Action oblige à définir des routes pour ces actions qui, par définition, ne seront jamais affichées “seules”."

Encore une fois, totalement faux. Jamais eu besoin de définir une route (enfin ce n'est peut-être pas ce que tu as voulu dire?), et heureusement que ces vues peuvent être affichées seules, notamment si on fait des sites en AJAX (C'est l'avenir, et même le présent, voir le passé aussi).

"Mais si vous souhaitez afficher un widget “Meteo” dans toutes vos pages, [...] Heureusement, il existe une bien meilleure alternative sous Zend Framework 2 : les aides de vue."

Tu conseilles donc d'appeler ton "aide de vue" dans toutes les pages de ton site? Il serait peut-être beaucoup mieux d'injecter dans une sous vue du layout, via l'event manager sur un mvcEvent::EVENT_DISPATCH, dans un $event->getViewModel(), les variables nécessaires? Avec un addChild par exemple... ou autre.

Voilà, j'ai argumenté, désolé.

bakura · 25-03-2013 14:12:02

Bah évidemment que j'insiste, tu peux pas venir comme ça et dire "80% d'informations erronées" et ne pas t'expliquer. Surtout qu'au vu de ton message et des arguments que tu avances, tu n'as clairement que survolé l'article.

Ravis d'apprendre que les aides de vue n'existaient pas dans ZF1.

Ou ai-je dit que les aides de vue sont une invention de ZF 2 ? Surtout que première ligne, je parle de ZF 1 et des aides de vue.

Ce que je dis c'est que sur ZF 1 la méthode utilisée pour résoudre ce problème de contenu par "widget" était résolue par une aide de vue spécifique qui A DISPARU du ZF 2.

De plus, mettre du métier dans un viewHelper, discutable, même si ce n'est pas si mauvais en soit.

Tu as donc lu l'article en diagonale, ça fait plaisir. Evidemment qu'inclure de la logique métier dans une aide de vue c'est pas top. D'où l'injection du service dans l'aide de vue, pour que la logique métier soit bien déléguée au service et non à l'aide de vue.

Totalement faux, les hooks de la boucle globale (controller plugins) ne sont effectuées qu'une seule fois. Seuls les hooks internes au dispatch, ceux des action helpers le sont, et c'est tout à fait logique et normal.

La dernière fois que j'ai utilisé ZF 1 remonte à longtemps, mais je te renvoie vers cet article : http://www.rmauger.co.uk/2009/03/why-th … -is-evil/.

Je ne vois pas ce que tu entends pas hooks et controller plugins ? De mémoire les plugins de contrôleur ne sont pas des hooks. Toujours est-il que la solution "préconisée" sur ZF 1 pour résoudre le soucis impliquait des problèmes de performances. Sur ZF 2, le plugin de contrôleur forward fait beaucoup moins de boulot (en l'occurrence, il se contente "presque" de ne changer que les paramètres du RouteMatch).

Encore une fois, totalement faux. Jamais eu besoin de définir une route (enfin ce n'est peut-être pas ce que tu as voulu dire?), et heureusement que ces vues peuvent être affichées seules, notamment si on fait des sites en AJAX (C'est l'avenir, et même le présent, voir le passé aussi).

Tu as à moitié raison. C'est surtout que sur ZF 1 les routes étaient plus ou moins automatique tant que tu suivais la logique /module/controller/action. Sur ZF 2 ce n'est plus le cas (à moins d'utiliser le ModuleRouteListener qui est un listener qui émule le comportement de ZF 1 mais qui n'est conseillé à être utilisé qu'en développement).

Donc sur ZF 2 il est conseillé de définir explicitement toutes tes routes. Si, pour une action donnée, tu souhaites y accéder uniquement via le plugin forward tu peux te dispenser de définir la route (car forward ne va faire que changer le paramètre "action" du RouteMatch, sans passer par l'étape de routage).

PAR CONTRE si tu souhaites y accéder via une requête Ajax, oui tu devras définir explicitement la route dans la config (encore une fois, sauf si tu décides d'utiliser la route "magique" qui émule le comportement de ZF 1).

Tu conseilles donc d'appeler ton "aide de vue" dans toutes les pages de ton site? Il serait peut-être beaucoup mieux d'injecter dans une sous vue du layout, via l'event manager sur un mvcEvent::EVENT_DISPATCH, dans un $event->getViewModel(), les variables nécessaires? Avec un addChild par exemple... ou autre.

Encore une fois, il n'y a aucune bêtise dans ce que j'écris dans l'article à ce propos. Ce que tu proposes est juste une autre solution que je pourrais effectivement ajouter à l'article. Cela dépend du cas. Si tu souhaites ajouter ça à aboslument toutes les pages, on peut appeler l'aide de vue dans le layout, ou effectivement ajouter un view model enfant. Au choix. Toujours est-il que si un module ajoute un listener à MvcEvent::EVENT_DISPATCH pour l'ajouter, cela nécessitera un peu plus de code si l'on souhaite supprimer l'évènement. Mais effectivement je suis d'accord avec toi, c'est une autre solution possible.

Voilà, j'ai argumenté, désolé.

Ouf, je suis rassuré, je n'ai donc pas vraiment dit de conneries ! ;-)

philippe · 25-03-2013 14:32:38

Salut,

Je viens de fermer le thread avant qu'on arrive au point Godwin.

Globalement méfiez vous, n'oubliez pas qu'on ne communique que par écrit sur un forum. On ne se connait pas en vrai, on ne connait pas le caractère ou même l'humeur du jour des gens en face.

Du coup il est important d'adopter le plus possible un ton assez neutre et plutôt sympa. La moindre agressivité, même légère, qui passerait comme une lettre à la poste à l'oral peut rapidement tourner au vinaigre dans un forum.

On est là pour aider les gens, soit en leur répondant directement, soit en augmentant la connaissance dans google. Restez sobres, c'est le meilleur moyen d'y arriver.

Le père la morale, (un peu dictateur aussi quand il ferme les threads sans préavis...),
Philippe

Zend FR

#1 21-03-2013 18:24:02

Accès à la base de données (model) avec le Layout

Code:

#2 21-03-2013 19:39:14

Re: Accès à la base de données (model) avec le Layout

#3 21-03-2013 21:04:45

Re: Accès à la base de données (model) avec le Layout

Code:

Code:

#4 23-03-2013 18:41:37

Re: Accès à la base de données (model) avec le Layout

#5 24-03-2013 22:51:34

Re: Accès à la base de données (model) avec le Layout

alien7 a écrit:

#6 25-03-2013 00:00:45

Re: Accès à la base de données (model) avec le Layout

#7 25-03-2013 01:42:45

Re: Accès à la base de données (model) avec le Layout

#8 25-03-2013 08:34:23

Re: Accès à la base de données (model) avec le Layout

#9 25-03-2013 11:12:29

Re: Accès à la base de données (model) avec le Layout

#10 25-03-2013 14:12:02

Re: Accès à la base de données (model) avec le Layout

#11 25-03-2013 14:32:38

Re: Accès à la base de données (model) avec le Layout

Pied de page des forums