Zend FR

Lorsque dans une page quelconque d'un module quelconque, on fait appel à des infos liées à un module particulier, on utilise des aides d'action (actionHelpers).
L'url détermine le module dans lequel on se trouve (sauf cas particuliers de routage).
Prenons par exemple la page d'accueil d'un site de rencontre (module default).
On y trouve la liste des derniers inscrits (appartenant au module membre) et les derniers temoignages des membres (appartenant au module temoignage).
Dans chacun de ces cas il faut écrire une aide d'action.

David

(suite)

Q.4/ Gérer l'application avec des /modules/ laisse sous-entendre en théorie que ces derniers ont un caractère portable d'une application à une autre non ?

Q.5/ Si globalement la réponse est "Oui" à la question 4/ : dans le cas d'interdépendances entre les fonctionnalités des modules et les pages, n'est-il pas plus judicieux d'avoir :
-> un module défaut qui possède des contrôleurs pour toutes les pages de l'application et qui use d'aides d'<action|vue> pour rapatrier des contenus de chaque autre module.
-> des modules par fonctionnalités (news, blog, ...), qui ne possèderaient que des aides d'action, aides de vues, et éventuellement des contrôleur (qui ne seraient jamais appelés par URL pour afficher une page) qui se contenterait d'injecter leur rendus dans le traitement du contrôleur du module "default" ?

Dernière modification par Eureka (19-08-2009 15:42:18)

Q5/ Dans le groupe de mot "aide d'action", il y a 2 mots : aide et action. On parle donc d'une assistance au travail de l'action. Le but d'une aide d'action n'est donc absolument pas de réalisé le travaille à la place des actions

Pour moi, un module n'est qu'un répertoire pour mieux classer sont travail (et éviter éventuellement des doublons dans le nom des contrôleur). Les bootstraps de module apporte de l'aide également dans ce classement

"dès lors je pense plus que des aides spécifiques à l'application doivent rester dans un sous-niveau quelconque de /application/. Je me trompe peut-être..."
Je vois ça de la même façon.


Concernant les modules le coté qui m'échape encore c'est l'orsque tu décide d'avoir des partis backend/frontend pour un module....

Certain font un controller frontend, un controller backend => bof si ton module est assez gros, tout avoir dans 2 fichiers :s

J'ai mis un autre post à ce sujet, j'explore quelques pistes...

Il y a une possbilité d'avoir un dossier dans controllers, exemple :

/monmodule/controller/backend/Article.php => http://domain.com/monmodule/backend_article   pour l'url

Mais bon le "_"  c'est moyen.

Eureka a écrit:

Merci pour ces nouvelles réponses


@nORKy :
(Q5) je veux bien un exemple argumentatif pour comprendre ton approche : de quelle manière (arbo modules éventuels + controller + helpers... ou autre) tu gèrerais l'affichage d'une page "espace perso" qui contiendrait à la fois : un mini agenda + dernières news du membre + quelques articles de blogs ?

Tu as surement choisi un mauvais exemple...

Pas besoin de module pour faire une page perso.

- MyaccountController()
-- indexAction()
--- $this->view->news = getTable('new')->findForUser('XX');
--- $this->view->agenda = $XX;
--- $this->view->blogData = getTable('blog')->findData('XX');

L'action s'occupe de gérer les paramètres éventuels (id utilisateur; nombre de news à affiché, ect...)
Je rajouterai surement un helper de vue pour le calendrier (mais qui reçoit les données venant du controller !)
La vue index.phtml s'occupe de mettre en forme les données (c'est son job)
Éventuellement, si tu veux réutilisé des "widgets" pour chaque zone, tu découpes index.html en aide de vue (qui prennent en paramètres leurs données !)

pour les news ? tu veux traité quoi ?? Généralement, les models ont déjà les fonctions de récupartion codées.
Pour ton affichages par pages, je suppose que tu parles de changé uniquement la "page" de news. Donc, tu fais appels à JS, donc à Ajax, donc, la tu as en effet un controller dédié (news/index/page/3)

hello

j'utilise pour faire ces genre de "widget" des aides de vues (par ex pour afficher les dernieres news sur la page d'acceuil) :

<?= $this->lastNews() ?>

J'ai donc une aide de vue dans mon module news (modules/news/views/helpers/lastNews.php, il faut bien s'assurer que ce dossier est pris en compte dans la recherche des aides de vue)
Cette aide de vue s'occupe de recuperer les données dont elle a besoin et renvoie un partial

return $this->view->partial('partials/last-news.phtml', array('items' => $item));

Ici l'aide de vue joue un peu le role du controlleur puisq'elle va invoquer le model pour recuperer ce dont elle a besoin, ce n'est peut etre pas tres propre à ce niveau la mais ca permet de tout garder dans le module et de simplement invoquer l'aide si on en a besoin ailleurs.

effectivement l'utilisation d'une aide d'action serait sans doute plus "propre" question mvc mais cela implique une deuxième "dépendance" vers le module à appellé (1 fois ds le controller et 1 fois dans la vue) ce que je voulais éviter

pour pas se casser la tete il y aurait aussi l'aide de vue action mais j'ai cru comprendre qu'il vallait mieux l'éviter pour des question de perf (cycle complet du mvc ZF pour juste rendre un cadre ...)


Pour revenir un peu sur le reste des questions :
- pour moi chaque module doit etre le plus indépendant possible des autres pour pouvoir facilement en ajouter/supprimer suivant le projet
- j'ai un module User qui est présent sur chaque projet (login etc...)
- certaines partie de ce module peuvent dépendre de la présence d'autre module, par exemple si un utilisateur peut s'inscrire et aller sur sa page /moncompte cette page va dépendre des autres modules (abonnement/désabonnement a la newsletter, suivi des commandes).
- Pour réalisaer cela sans avoir a modifier le code du module user, je créer dans les autres modules qui en ont besoin un plugin Users qui définit tout un tas de method qui vont etre appellée dans le module user; j'enregistre ces plugins dans le front controller au niveau du bootstrap du module

Exemple :

Action Helper pour récuperer les plugins "Users" ayant été enregistrés

class Etic_Controller_Action_Helper_UsersPlugins extends Zend_Controller_Action_Helper_Abstract
{
  public function direct() {
    $fc = Zend_Controller_Front::getInstance();
    $usersPlugins = array();

    foreach ( new DirectoryIterator(APPLICATION_PATH .'/modules/') as $module ) {
      $pluginName = ucfirst($module->getFilename()) .'_Plugin_Users';
      if ( $module->isDir() && ! $module->isDot() && $fc->hasPlugin($pluginName) ) {
        $usersPlugins[] = $fc->getPlugin($pluginName);
      }
    }

    return $usersPlugins;
  }
}

Le controller du module user

public function indexAction() {
    $this->view->title = 'Mon Compte';

    $this->view->usersPlugins = $this->_helper->UsersPlugins();
  }

La vue du module Users

<div id="menuClient">

  <p>
    <a href="<?= $this->baseUrl ?>/users/edit" title="Modifier mes coordonnées">
      Modifier mes coordonnées
    </a>
  </p>

  <p>
    <a href="<?= $this->baseUrl ?>/users/passwd" title="Modifier mon mot de passe">
      Modifier mon mot de passe
    </a>
  </p>

  <?php foreach ( $this->usersPlugins as $plugin ) : ?>

    <?= $plugin->userAccount($this) ?>

  <?php endforeach; ?>
  
</div>

Le plugin du module newsletters

class Newsletters_Plugin_Users extends Zend_Controller_Plugin_Abstract
{
  public function userAccount($view) {
    return $view->partial('partials/userAccount.phtml', 'newsletters');
  }
}

Le partial du module newsletters

<p>
  <a href="<?= $this->baseUrl ?>/users/newsletter/" title="Abonnement Newsletter">
    Abonnement à la newsletter
  </a>
</p>

J'pense qu'il doit y avoir moyen d'améliorer pas mal de choses (surtout pour des cas plus compliqués que afficher un lien) mais pour l'instant ca répond assez bien a mon besoin
Chez moi pour l'instant il n'y a pas d'histoire d'activation ou non du module, soit il est présent physiquement soit non.

j'espere que ca pourra aider

J'ai une petite question, d'un point de vue purement "logique Zend", vis à vis de ton utilisation des plugins : étant donné qu'ils servent à injecter du contenu dans une vue, ne leur as-tu pas affecté un rôle que tu aurais tout aussi bien pu ("logiquement dû", même) affecter à une aide de vue ? (avec exactement le même système sauf que l'helper ne récupèrerait pas des plugins mais des aides de vues)