Version imprimable
Bonjour,
Dans une application on a souvent besoin dans une vue de faire apparaitre un élements provenant d'une méthode d'un autre controller.
Sous cakePHP on utilise les "elements" qui permettent de faire ça...
Comment faut il faire avec Zend pour arriver au résultat souhaité ?
Un exemple serait beaucoup plus parlant pour expliquer ce que tu souhaites sans cela il est dur de comprendre
Par exemple lorsque je visualise la vue "liste" du controller "recette" je voudrai que dans une colonne du design apparaisse également le résultat de la méthode "lastArticles" du controller "article"
Tu peux utiliser les vues partiels si tu le souhaite
ça fonctionne comme ça ?
Code:
2
Code:
2
Code:
2
3
4
5
6
7
8
9
10je suis dans le phtml toto <h1>je suis le modelA</h1> $this->toto; j'appelle le modèle B a traver phtml2 <h1>je suis le moduleB</h1> <?php echo $this->partial('phtml2.phtml', $this->tata; ?>
Tu devrais tester avant de mettre ce genre de chose
La vraie question est pourquoi tu veux faire ça...
Souvent ce type de demande révèle une mauvaise pratique.
Si tu as besoin des derniers articles, c'est ton modèle qui doit te donner le résultat, pas un contrôleur. Donc dans ta méthode listeAction() de ton contrôleur Recette, tu pourrais récupérer les derniers articles depuis le modèle (= un appel de méthode, au pire avec une instanciation d'objet, 2 lignes), et l'ajouter à la vue (1 ligne).Citation:
Envoyé par siriu
Rien n'empêche par contre de factoriser ton code de vue dans un phtml dédié, et de l'appeler dans chacune des vues où c'est nécessaire par un simple :
Code:echo $this->render("derniers-articles.phtml");
Le problème c'est que souvent les développeurs écrivent la logique métier dans le contrôleur, au lieu de le faire dans le modèle. C'est ainsi qu'on se retrouve avec une application difficilement maintenable, avec du code mal placé et souvent dupliqué, et qu'on a besoin d'appeler des méthodes de contrôleur dans un autre...
Le modèle est souvent perçu comme une simple couche d'accès à la base de données, alors qu'en fait c'est bien plus que cela. C'est tout l'intérêt de l'objet : embarquer la logique dans les objets métier, pas seulement traiter la persistance.
Bref, la bonne réponse à ta question est de refactoriser ton code pour ne pas avoir à faire ce genre d'appel, qui n'a pas vraiment de sens ;)
Un contrôleur doit se contenter de jouer le chef d'orchestre :
- recevoir l'input utilisateur
- le valider et le transmettre au modèle pour traitement
- ajouter les résultats provenant du modèle dans la vue
Je le répète encore, la logique métier doit s'implémenter dans la couche métier, c'est-à-dire dans le modèle.
En effet et sur Zend je dirais même plus au niveau des rowClass et non au niveau de DbTable, car la rowClass représente un seul objet.
La logique peut être aux 2 niveaux ça dépend des cas. ;) Quand je parle de "modèle" c'est au sens large.Citation:
Envoyé par 5h4rk
Typiquement tu peux avoir besoin d'une méthode de sélection fine d'un ensemble de lignes (= objets), dans ce cas la méthode se trouvera bien au niveau de l'objet repository (DbTable), et pas l'objet Row ;)
En effet mais je parlais et je pensais que toi aussi, des methodes qui s appliquent aux objet donc a un row et non pas un rowset
Si l'affichage du dernier article doit persister au niveau du layout, il serait plutôt conseiller d'utiliser soit l'actionStack, soit l'aide de vue "action()".Citation:
Envoyé par siriu
par contre, si tu doit appeler ta méthode "lastArticles" dans une autre action, je te déconseille ce genre de méthodes qui vont, comme dit précédemment rendre beaucoup moins lisible ton code.
Et dans ce cas, comme le dis ovh, il vaudrait mieux faire appel à tes deux modèles "articles" et "recettes" dans ton contrôleur. Mais le problème qui va apparaître c'est que tu vas faire des appels au modèle "articles" dans ton contrôleur "recette"... Peut-être faudrait-il renommer tes contrôleurs pour plus de cohérence ?
Je ne vois pas en quoi c'est un problème ? :roll:Citation:
Envoyé par Alcide_
Un contrôleur n'est pas obligé de n'utiliser qu'une seule classe métier, encore heureux :mouarf:
Complètement d'accord, je n’émettais que l'hypothèse d'un renommage de contrôleur car, de ce que j'en avais compris, son organisation actuel paraissait assez "crudienne" (un contrôleur par type de ressource) et non pas par page.
Mais, si mon message porte à confusion, je m'en excuse et ne peux que te citer :
Citation:
Envoyé par ovh