Zend FR

Si ton controleur a trop d'action, et sans pour autant faire des modules, tu devrais voir si y a pas des themes qui se decoupe dans tes actions et faire plusieurs controlleurs au lieu d'un gros.

Les modules sont pour moi un découpage de plus haut niveau, une section d'un site par exemple.


D'autres pistes a tester :
- Ajout d'une partie statique a ta route mais ca reviens un peu a faire des modules, moi j'ai fais ca car le découpage module/controller/action n'est pas suffisant pour moi.

- utilisation de /param/value pour faire un proxy routage au sein de l'action genre /subaction/subactionname

- Solution du meme acabit que les actionHelpers.

philippe a écrit:

Pour faire ça, tu peux sous-classer Zend_Controller_Action et réécrire la fonction dispatch. Ensuite tu peux faire hériter tes controlleurs de ta classe My_Controlleur_Action au lieu de Zend_Controller_Action.

A+, Philippe

Je n'avais pas vu ta réponse, merci infiniment, je vais regarder ça

fred wolf a écrit:

Cyrano,

il me semble qu'il existe un proposal visant à utiliser des fichiers pour stocker les actions comme tu l'as décrit dans ton exemple.
Si mes souvenirs sont bons tu trouveras une réponse à ton problème.
Le W(ea)ky de ZF étant encore en vrac, je n'ai pu retrouver le lien.

Fred

Je vais fouiller dans la soirée, dans l'immédiat, je suis au bureau et j'ai trop de travail.. :?

Je te remercie beaucoup

Dernière modification par Cyrano (04-07-2007 12:13:50)

Le controller doit etre un nom de controller, tel que dans la conception, pas de classe ou de fichier.
Au meme titre, tu peux spécifier un module, et pour moi, le premier parametre est l'action pas le repertoire.
Enfin, le dernier parametre represente les parametres que tu souhaites passer dans le request object.

C'est bien a ca que je répondais. Admettons que tu ais un controller cont2  Nom de fichier cont2Controller.php donc, sur lequel tu souhaites forwarder, et bien tu utilises la string 'cont2' pour le parametre controller. Au meme titre que pour l'action, tu utlises le nom conceptuel de l'action (ex: edit) et nom pas le nom réel (editAction).

2 remarques rapides déjà, je regarderai plus avant après.

Dans ton front controller, tu ajoutes les paths vers les rep de controllers en indiquant un rep 'controllers', hors on ne retrouve pas cette arbo dans la description juste au dessus, en fait, d'apres la description au dessus, il ne faudrais pas mentionner le rep 'controllers' mais se limiter a index/ ou auth/.

$frontController->setControllerDirectory(array(
        "default" => $appDir .'application'. $ds .'controleurs',
        "index"   => $appDir .'application'. $ds .' index '. $ds .'controleurs',
        "auth"    => $appDir .'application'. $ds .' auth '. $ds .'controleurs'
    )
);

2/ Dans l'init de ton controller, tu met la vars $Ctrl a $Action . 'Controller'. D'apres ce que j'ai compris, il attend un nom de controller conceptuel, a savoir dans ton cas, $Action, et il ne faut pas non plus prefixer par un path, il cherchera lui meme dans la liste des rep de controller ou trouver ce controller. Mais attention au collision, car ta methode ne gere pas de namespace contrairement au module.

Bah, y a un pb de path très probable, et si tu utilises la methode forward, il ne faut pas indiquer de chemin physique ni de nom de class mais les memes items qui serait utiliser dans l'url si c'étais le cas. Meme si je n'ai pas compris ce que tu veux faire, ca ne change rien au fonctionnement du ZF et aux remarques que j'ai faites. Tu ne fera jamais fonctionner la methode forward avec un parametre controller ainsi nommé, et le dispatcher ne trouvera pas les controller si les path vers les controllers ne sont pas bon. Désolé de ne pas etre plus clair non plus

Dernière modification par TiTerm (08-07-2007 20:16:15)

Alors, une petite précision sur forward(). Cela ne transfert pas directement mais permet d'établir une chaine. En fait, il ajoute dans la queue le prochain controller/action a dispatcher mais c'est tout. Cad que le controller et l'action courante seront qd meme exécuté. Donc dans le controller courant, il te faut un moyen pour 'catcher' l'action puisque la vraie action sera dans un autre controller "caché" dans un sous rep.
De plus, du fait du moment ou est appelé l'init() d'un controller, je crois qu'on ne peux pas faire de forward vers un autre controller depuis l'init(). Il faut donc déplacer ton  forward dans une autre méthode.

Comme il te faut catcher l'action courante, le plus simple est d'utiliser la methode __call pour que le controller Index puisse trouver une réponse à l'action Accueil par exemple, meme si elle ne se trouve pas physiquement ici. Dans __call, tu met ton forward() (eg : forward('index','ajouter') ). Au retour du _call, le dispatcher reprend la main et constate qu'il y a encore du boulot. A savoir aller dans le controller Acceuil par exemple et executer la methode Action que tu auras indiqué dans le forward.
A partir de la, tu devrais déjà avoir avancé, il forward, reste a savoir si il trouve le controller secondaire.
Si il le trouve, Bingo. Si il te réponde que le controller n'existe pas, c'est que ta pile de path vers les controller n'est pas bonne.
Alors, qd on utilise des modules on peut redéfinir le nom du répertoire qui héberge les controllers via setModuleControllerDirectoryName() mais je n'ai pas vu quelque chose d'équivalent sans les modules. Tu es donc (sauf erreur de ma part) condamnée a modifier ton arbo et a ajouter sous auth et index un sous répertoire controllers dans lequel tu mettras tes sous controllers identification, login, etc...

une derniere raison pour laquelle il pourrait ne pas trouver les controller. Un pb de casse suivant ton environnement. Si c'est sous unix, attention a tes sous controllers : AjouterController.php et loginController.php.

Courage

Dernière modification par TiTerm (08-07-2007 22:42:37)

fred wolf a écrit:

Cyrano,

est-ce que tu cherches à faire ça ?

Fred

heu... possible, je ne sais pas, je vérifierai ça en rentrant chez moi ce soir. En journée, je n'ai vraiment pas le temps, donc impossible de te répondre dans l'immédiat et au bureau, on utilise pas le ZF (Il n'était qu'en version 0.6 quand le projet a été lancé) mais un framework maison.

fred wolf a écrit:

En fait, je ne crois que le lien que j'ai posté précédemment corresponde à ce que tu veux.

Par contre, il y a fort longtemps, il y eut une discussion à ce sujet :

http://www.nabble.com/Action-files-tf36 … #a10094063

C'est très exactement la nature du problème que j'ai soulevé. Je vais regarder ça de beaucoup plus près ce soir, je suis certain que la solution n'est plus très loin

Encore merci. Si ça roule, je viendrai modifier le tag du titre de ce sujet et accessoirement je donnerai la solution si j'arrive à faire quelque chose de présentable et proprement codé

Effectivement tu peux redéfinir le chemin des vues. Il s'agit d'une pile, tu peux ajouter des chemins avec
$view->setScriptPath('/chemin/de/ta/vue');
Le dernier ajouté sera le premier visité afin de trouver la vue désirée.

Ca c'est le comportement de base, maintenant, depuis l'avènement du ViewRenderer, tu peux aussi agir sur les chemins.

Tu pourras glaner plus renseignements dans la doc.

A+

fred

Après exploration, il semble que ce soit moins compliqué, mais je tombe sur une exception qui, à priori, est incohérente.

Je pars de l'url suivante : http://localhost/zf-tutorial/accueil_accueil/accueil

Dans mon IndexController, j'ai ajouté la modification suivante dans la méthode init():

//....
        $this->view->setScriptPath($this->view->baseUrl . self::SR .'application'. self::SR .'vues'. self::SR .'templates');
        $this->view->addScriptPath($this->view->baseUrl . self::SR .'application'. self::SR .'vues'. self::SR .'templates'. self::SR .'accueil');
//....

Et le résultat est correctement pris en compte.

J'ai toutefois ajouté dans ma méthode d'action :

$this->view->render('accueil.phtml');

Seulement voilà, j'obtiens ceci :

Fatal error:
Uncaught exception 'Zend_View_Exception'
  with message 'script 'accueil.phtml' not found
  in path (\zf-tutorial\application\vues\templates\accueil\;\zf-tutorial\application\vues\templates\)'
  in C:\www\zf-tutorial\librairie\Zend\View\Abstract.php:856
Stack trace:
  #0 C:\www\zf-tutorial\librairie\Zend\View\Abstract.php(764):
      Zend_View_Abstract->_script('accueil.phtml')
  #1 C:\www\zf-tutorial\application\controleurs\accueil\AccueilController.php(20):
      Zend_View_Abstract->render('accueil.phtml')
  #2 C:\www\zf-tutorial\librairie\Zend\Controller\Action.php(497):
      Accueil_AccueilController->accueilAction()
  #3 C:\www\zf-tutorial\librairie\Zend\Controller\Dispatcher\Standard.php(237):
      Zend_Controller_Action->dispatch('accueilAction')
  #4 C:\www\zf-tutorial\librairie\Zend\Controller\Front.php(909):
      Zend_Controller_Dispatcher_Standard->dispatch(Object(Zend_Controller_Request_Http), Object(Zend_Controller_Response_Http))
  #5 C:\www\zf-tutorial\index.php(44):
      Zend_Controller_Front->dispatch()
  #6 {main}
    thrown in C:\www\zf-tutorial\librairie\Zend\View\Abstract.php on line 856

Je comprends d'autant moins, j'ai traqué la moindre erreur d'écriture dans les noms des fichiers ou répertoires, rien à faire : le fichier est bien là où c'est indiqué mais le viewRenderer semble avoir perdu le sens de la vue...

Une idée ?

Ça ne fonctionne pas mieux et je n'ai pas un résultat différent..... Me semblait que le développement du ZF était assorti de l'objectif "extreme simplicity" : c'est pas gagné

Je soupçonne en outre autre chose : les "/" sont automatiquement transformés en "\" dans les chemins : ça peut être suffisant pour me bousiller le système, j'ai déjà eu des problèmes avec ça.