Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Pages: 1
Bonjour,
Dans une vue associée à un module/controleur/action je tente d'appeler une aide de vue présente dans un autre module, et cela ne fonctionne pas :
<?php echo $this->testHelper(); ?> // provoque Plugin by name 'TestHelper' was not found in the registry; used paths: Zend_View_Helper_: Zend/View/Helper/:/home/[...]/My/application/controllers/views/helpers/
Du coup j'ai cherché à visualiser les chemins des aides de vues, et le résultat est relativement différent d'un module à l'autre :
// Dans un contrôleur, via l'instruction : Zend_Debug::dump($this->view->getHelperPaths(), ''); // CAS 1 : renvoie dans le module par défaut : array 'Zend_View_Helper_' => array 0 => string 'Zend/View/Helper/' (length=17) 1 => string '/home/[...]/My/application/controllers/views/helpers/' (length=102) // CAS 2 : renvoie dans un module situé dans /modules/ (ici 'agenda'): array 'Zend_View_Helper_' => array 0 => string 'Zend/View/Helper/' (length=17) 'Agenda_View_Helper_' => array 0 => string '/home/[...]/My/application/modules/agenda/views/helpers/' (length=72)
Les deux modules ont toutefois défini un autoloader (Zend_Application_Module_Autoloader) dans le bootstrap et pour vérification voici le var_dump() de chacun d'eux :
// module par défaut, namespace : '' 'View_Helper' => string '/home/[...]/My/oboza/trunk/application/views/helpers' (length=56) // un autre module, namespace : 'agenda' 'Agenda_View_Helper' => string '/home/[...]/My/application/modules/agenda/views/helpers' (length=71)
Dans le CAS 1, je trouve cela étrange que ZF adopte le comportement par défaut des chemins de vues pour les aides (/controllers/views/...) alors que l'autoloader spécifie le chemin réel, de plus il associe ce chemin au namespace 'Zend_View_Helper_' plutôt qu'à une chaîne vide (qui est sensé être le namespace du Z_L_Module_autoloader du module par défaut) ?
Dans le CAS 2, le chemin est associé au bon namespace et fonctionne si j'appelle l'aide de vue dans un fichier de vue appartenant au même module.
En revanche si j'appelle l'aide de vue dans un fichier de vue du module par défaut là ça coince (cf. erreur saisie au début du message)
Si quelqu'un a une idée qui lui traverse l'esprit...
Merci
Hors ligne
Quelqu'un a une idée ?
L'idée serait au sein d'un module de pouvoir accéder aux aides de vues des autres modules.
Hors ligne
Salut,
Pour moi tout ce qui n'est pas spécifique à un module ne doit pas se trouver dans le module mais en dehors.
Si c'est une aide de vue générique, ça va dans library, sinon dans views/helper/ si tu as l'arbo par défaut (Chez moi "templates/default/helper).
A+ benjamin.
Dernière modification par Delprog (17-09-2009 14:16:02)
Hors ligne
Merci.
Pour expliciter mon besoin, en fait je suis parti sur une arborescence composée d'un module par défault, et de modules axés sur des fonctionnalités bien particulières (agenda, news, groupes d'utilisateur, ...).
En partant du principe qu'une même page peut afficher des éléments de chaque modules, toutes les pages de l'applications sont liées à des contrôleurs du module par défaut.
Dès lors, seuls mes contrôleurs du module par défaut sont sollicités par des URLs. Afin qu'il rappatrient en leur vues les fonctionnalités attendues, je suis amené à interroger les modules pour qu'ils ramènent leur contenu dans la vue du contrôleur sollicté.
Pour cela j'ai pensé à divers moyens :
- l'aide de vue "action" pour qu'un module rappatrie son contenu avec traitement metier (solllicite un contrôleur du module et rend la vue du module)
- l'utilisation d'aides d'action appartenant aux modules au sens des contrôleurs par défaut, pour opérer des traitement métier. Ces aides d'actions des modules peuvent attribuer des variables à la vue qui seront utilisées dans la vue du contrôleur par défaut.
L'aide d'action "action" semblant être un traitement peut optimisé en soit, je pense donc m'orienter vers une exploitation des modules via des aides d'actions simplement.
Mais la problématique ici est :
- soit l'aide d'action opère un view::partial() pour rendre sa propre vue et l'injecter dans une variable de la vue des contrôleurs par défaut
- soit l'aide d'action opère des affectations de valeurs aux variables de la vue du contrôleur par défaut ; la vue du contrôleur opérant alors elle-même un partial en passant en paramètre les variables qu'ont injectées les aides d'actions, OU BIEN appeler une aide de vue (qui connaissant la vue peut exploiter les variables des aides d'actions directement)
Le but au final étant qu'un module peut opérer un traitement (récupérer des "évènements datés" par exemple) et rendre sa propre vue (le rendu d'un agenda représentant les évènements datés par exemple). Ce rendu étant injecté dans la vue du contrôleur sollicité vues des par l'URL, en plus des autres vues des autres modules devant apparaitre sur la page.
Peut-être dès lors devrais-je ne pas utiliser du tout d'aide de vues pour solliciter un module, mais juste view::partial() ?
Hors ligne
Avec les partials tu pourras rendre la vue du module souhaité, mais tu devras passer à la main les paramètres. Le controlleur du module concerné ne sera pas dispatché.
Je ne sais pas comment t'aider sans que tu casses tout. Le problème est que tu as du traitement métier dans le controlleur. C'est vrai qu'utiliser l'actionStack un peu à tout va est plutôt consommateur de ressources. Je l'utilise uniquement pour mon module "Auth", rien d'autre.
Je n'ai jamais de traitement métier dans mes controlleurs. Si j'ai des news à afficher à diverses endroits, je passerais toujours par un Service_News que je vais consommer dans chaque controlleur concerné.
Si la vue est identique d'un module à l'autre, alors je peux utiliser un partial et lui envoyer le résultat de mon service (donné par le controlleur).
A+ benjamin.
Hors ligne
Tout le monde n'a pas la chance d'avoir des Service_* ! :p
Dans l'idée, même avec un Service_* j'aimerais autant que le service soit consommé, pour une fonctionnalité donnée, dans une classe gérée par le module concerné. Je conçois plus l'utilisation de Service_News dans un contrôleur ou une aide d'action du module "news" qu'une sollicitation direct dans un contrôleur de page (module "default").
Dans le cas par exemple d'un agenda, mon "contrôleur de page" pourrait déclencher un "évènement" demandant à chaque module de rappatrier les éléments à afficher dans l'agenda (évènements, annonces, ....) puis appelerait une aide d'action du module agenda, en lui transmettant les données à y afficher, qui elle se chargerait d'instancier une classe agenda et la conserver en session, d'ajouter le fichier javascript qui va bien, ... et autres choses ..., pour au final transmettre à la vue du contrôleur de la page la vue rendue par l'aide d'action agenda.
(Peut-être pas très clair hein ?)
Hors ligne
demandant à chaque module de rappatrier les éléments à afficher dans l'agenda (évènements, annonces, ....)
Si seuls tes modules ont accès aux données qui les concernent, dans le MVC, le seul moyen de faire ça est de stacker des actions et même si tu utilises une vue unique qui récupère l'ensemble des informations.
Un helper ne te sera pas d'une grande aide ici.
Il n'y a pas beaucoup de solutions, soit tu stack les actions, soit tu répètes le code des controllers concernés dans ton controller, soit tu externalises le traitement. Sinon je ne vois pas
A+ benjamin.
Hors ligne
Salut,
Si je stack les actions, les appels de contrôleurs vont s'enchaîner après que chacun d'eux ait fini son propre traitement, je ne pourrais pas appeler entre deux instructions d'un même contrôleur d'autres actions/contrôleurs du coup.
Si je ne me trompe chacun rendrait sa vue à la suite des actions précédentes (ce qui ait problématique lors de mises en pages d'éléments qui ne sont pas apte à être simplement empilés les uns à la suite des autres).
L'alternative serait éventuellement de placer la vue de chacun dans des placeholders, et d'injecter le tout dans un fichier de vue au final, mais du coup la vue de chaque page serait plutôt un layout qu'un views/scripts pour agencer tout cela qu'au rendu final.
Il me semble possible de contourner cela en exploitant des aides d'actions d'autres modules (qui eux sont bien accessibles au sein d'un contrôleur d'un module quelconque).
Concernant les aides de vues inter-modules, je ne vois pas trop de solutions (à part éventuellement ajouter tous les chemins vers les aides de vues des modules au bootstrap, ou demander aux aides d'actions d'ajouter à la vue en cours le chemin des aides de vues du module pour qu'elles soient exploitable dans une vue quelconque). Ou, tout bonnement m'en passer si cela n'est pas vraiment recommandé !
En tout cas merci pour ces idées/retours ;-)
Hors ligne
Pages: 1