Zend FR

N'est il pas plus intéressant de définir les rôles à la volée plutôt que de tous les définir à l'avance ?

Rien ne t'empêche de définir des rôles à la volée en utilisant les Acls, non ? En tout cas, c'est comme ça que je procède, mes rôles, actions et modules sont dans une base de données et je charge à la volée.

Dernière modification par whitespirit (15-07-2008 12:26:03)

Alors la question suivante va être la façon de stocker les données afin d'être le plus évolutif possible dans l'application.
Comme je l'ai indiqué au départ de ce post, le but est de proposer un back office avec un core comprenant les fonctions essentielles à la gestion même du BO ainsi que les briques indissociables (selon ma vision, hein, pas la peine de partir en troll la dessus ;-)) du core que peuvent être :
- la gestion des utilisateurs
- la gestion de l'authentification
- la gestion de news
- la gestion de newsletters
- la gestions des droits (ACL)
- etc.

Par contre, comment être sur que l'application et notamment son modèle de données pourra évoluer sans aucun problème ?

Avez vous des propositions sur ce point particulier ? Un mode de stockage différent de ce qui se fait traditionnellement ? J'ai commencé à me documenter sur RDF mais le web sémantique, ce n'est pas forcément évident et je ne suis pas sur que cela réponde forcément à ma problématique.

[Edit] alors pour voir comment s'organisent les datas avec RDF, vous pouvez jetter un oeil ici (le graphe en bas de page nommé RDF and the Semantic Graph) : http://www.twine.com/tour/semantic. Cela à l'air intéressant mais sans doute complexe à mettre en place. Merci de vos retours...

[Edit 2] Une bonne source d'information sur le RDF : http://websemantique.org/PagePrincipale

[Edit 3] Peut être le modèle de wordpress avec son système de plugin est il un bon exemple d'évolutivité d'pplication. Qu'en pensez vous ?


Cordialement,

Dernière modification par elkolonel (22-07-2008 10:50:20)

On a également developpé un système de BO avec ZF.
On est parti sur un arbo comme celle la :

library
   Zend
   MaLibrairie
   ...
application
   default
      controllers
      models
      views
   fr
      controllers
      models
      views

      admin (la gesiton globale du BO)

      menu
          controllers
          models
          views
          install
      news
          controllers
          models
          views
          install
      utilisateur
          controllers
          models
          views
          install

www
   index.php
   /public
        /fr
            images
            css
            js

Ainsi, on peut ajouter, ou enlever un module très facilement, et chaque module contient sa partie BO et FO.

Pour les évolutions des modules, effectivement, c'est le problème, s'il y a des gros changements dans la structure de la table, ou même du ZF (1.0 et 1.5 avec les layouts), alors dans le dossier install, je gère les différences entre les verisons, et fait les adaptations sur la structure de la base et sur les fichiers s'il le faut...

Salut Aurelien,

j'aurai 2 questions sur ta structure si tu veux bien :

  * Qu'est ce que contient le répertoire admin ?
  * Tout tes modules on l'aire de se trouver sous /fr comment ça se passe si je rajoute une langue ?

@+

elkolonel a écrit:

mais en fait le répertoire admin va contenir tout ce qui va être proprement dit le back-office. Tandis que les autres répertoires, tels que 'menu', 'news' seront la partie front office de l'application. Le côté back-office du module de news sera par exemple gérer par le controlleur situé dans 'application/fr/admin/controllers/NewsController.php avec les actions AddAction, ListAction, EditAction par exemple...?

Apparemment ce n'est pas ce qu'a l'aire de dire Aurelien :

Aurelien a écrit:

Ainsi, on peut ajouter, ou enlever un module très facilement, et chaque module contient sa partie BO et FO.

D'où ma question

elkolonel a écrit:

Pour ce qui est de l'organisation multilingue, est il nécessaire de tout dupliquer dans des répertoires de langues. N'est il pas plus simple d'utiliser le mode gettext de zend_translate avec des fichiers po (en liaison avec le logiciel PoEdit : http://www.poedit.net/index.php) ?

Effectivement  je pense que la bonne approche et d'utiliser le routeur pour simuler un répertoire de langue
http://www.z-f.fr/forum/viewtopic.php?id=552 et l'utilisation de zend_translate et/ou une vue par langue.

elkolonel a écrit:

Merci pour ta réponse Aurélien, ma structure a évolué et s'approche de la tienne. Il me reste à résoudre le souhait de mes webmasters, designers pour que tout soit parfait.

Cordialement,

Alors mes problèmes liés à mes webmasters et designers sont résolus, j'ai réussi à tout placer (déplacer) dans un seul répertoire grâce aux commandes suivantes :

$viewRenderer->setViewBasePathSpec('/path_to_application/application/design/basic')
        ->setViewScriptPathSpec(':module/:controller/:action.:suffix')
        ->setViewScriptPathNoControllerSpec(':action.:suffix')
        ->setViewSuffix('html');

C'est vraiment là que l'on s'aperçoit de la souplesse et de la puissance du ZF... ;-)

Maintenant, je me pose la question suivante, sachant qu'un back-office ne fonctionne pas sans un front office, est il possible dans le bootstrap de définir un layout pour le front office et un layout différent pour le bo ?

Un retour d'expérience sur cette question ?

Aurelien a écrit:

Dans admin, j'ai mon controller admin, qui me permet de pinter mon application sur http://monapplication/fr/admin.

Dans mon bootstrap, je parse tous les modules, regarde s'ils sont actifs ou pas, et défini dynamiquement les PATH de views, model, et controller.

Alors c'est là que cela devient intéressant, peux tu me dire comment tu définis dynamiquement des PATH de views ?
Car je me retrouve de nouveau confronté à un problème (sans doute par méconnaissance de la globalité du ZF...). Pour mes webmasters, designers, j'ai réussi à tout caler dans un seul répertoire 'design' qui se trouve au même niveau que le rep. 'application'. J'ai fait de même pour mes modules. Afin qu'ils soient totalement indépendant, je les ai sorti du répertoire application (comme le propose seikajin : http://zend-framework.developpez.com/se … siers/#LIV).

Toutefois, rappelez vous j'ai défini dans mon bootstrap un endroit personnalisé pour mes vues (afin que mes designers et graphistes puissent travailler avec tous les fichiers regroupés)

$viewRenderer->setViewBasePathSpec('/path_to_application/application/design/basic')
        ->setViewScriptPathSpec(':module/:controller/:action.:suffix')
        ->setViewScriptPathNoControllerSpec(':action.:suffix')
        ->setViewSuffix('html');

et maintenant comment puis je gérer les vues des modules ? Le but d'un module est de le déposer, de modifier quelque peu sa config et qu'il fonctionne. Cela implique d'avoir les vues qui concernent le module dans un sous répertoire de celui-ci... mais alors fini la centralisation des vues pour mes designers...

Avez vous une idée, car là j'ai l'impression de marcher vers un mur dans mon organisation...

Qu'en pensez vous ?

Roulio a écrit:

Je pense que dans une organisation comme celle que tu recherche tu dois obligatoirement un jour trancher entre :

1 - avoir des modules complètement autonome ce qui implique une séparation des dossiers de vue pour tes designers.
2 - soit centraliser les vues et perdre la gestion autonome des modules.

bah c'est un peu une réponse sans fond, je crois qu'il faut juste faire un choix... Tout dépend de ce que tu recherche, faciliter la gestion des modules ou faciliter la vie de tes designers

Merci Roulio, je crois que tu viens de me donner la solution.

En fait, il faut considérer le module comme un élément indépendant mais pas forcément refermé sur lui-même. L'ajout d'un module sur l'application peut effectivement consister en l'ajout d'un répertoire module mais peut également mettre en place les fichiers nécessaires au templating dans le répertoire design. Le tout est d'avoir des noms et une arborescence suffisamment bien pensée pour ne pas écraser de fichiers de vue/layout/theme d'autres modules.

Contenu du package du module auth (par exemple) :

[auth.zip]
   /application
      /design
         /theme
            /scripts
               /auth
                  /login.html
   /auth
      /controllers
      /models
      /sql
      /config

Comme cela, il suffit de le dézipper à la racine et de lancer son installation dans le back-office et le tour est joué.

Je vais tester cela mais je pense en effet qu'il s'agit de la bonne solution...

Merci Roulio. ;-)

Bonjour,

Je suis également intéressé par un retour d'expérience !

Merci

Salut,

Ce n'est pas lourd à mettre en place avec une bonne gestion de la config.

Par exemple une classe qui load la config en fonction du module dans le frontController.

De mon côté je ne met rien ou presque dans le bootstrap.

J'ai un plugin d'initialisation commun à toute l'appli, que j'appelle depuis le bootstrap en passant en paramètre le nom du module.

Ensuite dans le plugin d'initialisation j'utilise une classe qui se charge de loader l'environnement et toute la config du module en question, et tout se fait automatiquement.

J'accède ensuite indépendamment, grâce à une classe dérivant Zend_Registry, à ma config (fichier ini lié à l'environnement : dev, test, prod, etc.) et aux paramètres (fichier ini contenant tous les paramètres de l'appli en elle même, donc qui ne changent pas quelque soit l'environnement).

Je pense que séparer les config et paramètres du front et du back est une bonne solution.


A+ benjamin.

Dernière modification par Delprog (21-01-2009 16:03:46)

Salut,

Dans ma classe d'initialisation je commence par appeler une classe Tight_Config en passant en paramètre le chemin du fichier qui décrit l'environnement. C'est à dire celui contenant le nom du fichier ini de config à utiliser (qui change en fonction de l'environnement), et le fichier de paramètres (tout le paramétrage lié à l'application elle-même, routes, vues, controllers, ACL, langues, etc.) à utiliser par l'appli.

Cette classe de config redéfinie le Registre pour utiliser encore une fois un registre personnalisé Tight_Registry, depuis lequel j'accède à toutes les méthodes du Zend_Registry + des méthodes qui me renvoient soit la config, soit les paramètres.

Suite à ça, je continue l'exécution de mon initializer et configure chaque partie indépendamment (un peu comme l'initializer proposé par Zend Studio for Eclipse) automatiquement en fonction du fichier de paramètres.

$this->initDb();          
$this->initCache();
$this->initLanguage();       
$this->initView();
$this->initHelpers();        
$this->initPlugins();
$this->initRoutes();        
$this->initControllers();

exemple pour la vue :

    /**
     * Initialise la vue en fonction des parametres définis dans
     * Tight_Registry::getParams()
     * ou avec des valeurs par défaut
     * 
     * @return void
     */
    public function initView()
    {                    
        Zend_Loader::loadClass('Tight_View');                
        $this->_view = new Tight_View();

        // Si des config de scripts sont présentes dans le fichier de paramètres
        $scripts = Tight_Registry::getParams()->get('view')->get('scripts', null);
        if (!is_null($scripts)) {
            foreach($scripts as $script) {
                $this->_view->addScriptPath($this->_moduleRoot . $script->scriptPath);
            }
        }   
        
        // Si aucune config n'a été donné pour les scripts, config par défaut
        $scripts = $this->_view->getScriptPaths();
        if (empty($scripts)) {     
            $this->_view->addScriptPath($this->_moduleRoot . '/views/scripts');
        }        
                
        /**
         * Configure l'url complète de l'accès public dans la variable _httpRoot de la view
         * Accessible ensuite par $this->_httpRoot, voir Tight_View
         * @see Tight_View
         */ 
        $this->_view->setHttpRoot(Tight_Registry::getConfig()->app->get('httpRoot', ''));
        
        $doctype = Tight_Registry::getParams()->get('view')->get('doctype', 'XHTML1_STRICT');
        $this->_view->doctype($doctype);        
        
        $encoding = Tight_Registry::getParams()->get('view')->get('encoding', 'UTF-8');
        $this->_view->setEncoding($encoding);
        
        // Chargement de la config du layout depuis le fichier de paramètres, sinon valeur par défaut
        $layoutPath = Tight_Registry::getParams()->get('view')->get('layoutPath', '/application/views/layouts');
        $defaultLayout = Tight_Registry::getParams()->get('view')->get('defaultLayout', 'layout');
        Zend_Layout::startMvc(array(
            'layoutPath' => $this->_moduleRoot .  $layoutPath,
            'layout'     => $defaultLayout            
        ));
        
        // Recupère l'objet de vue utilisé par les actions des controllers
        $viewRenderer = Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
        $viewRenderer->initView();
        $viewRenderer->setView($this->_view);
        
        Tight_Registry::set('view', $this->_view);
    }

et dans le fichier de paramètres :

[view]
scripts.script1.scriptPath = "/views/scripts"

doctype = "XHTML1_STRICT"
encoding = "UTF-8"

layoutPath = "/views/layouts"
defaultLayout = "layout"

Même principe pour le reste.

En gros, je suis parti du plugin d'initialisation proposé par Zend Studio for Eclipse, je l'ai greffé à ma classe gérant la config et automatisé.

Pour la classe Tight_Config, j'ai mis en place un fonctionnement assez proche de ce que propose sekaijin dans son blog, que je remercie au passage car même si nos classes restaient assez différentes, son expérience m'a permis d'améliorer quelques points incertains dans ma classe.

A+ benjamin

merci beaucoup delprog, mais ça confirme quand même ma pensé :
Default : - Lourdeur de mise en place.

Je ne suis pas d'accord

Tout ça me permet de créer un squelette d'application une bonne fois pour toute.

Lors d'un nouveau projet, je copie mon squelette, j'en fais un projet et je n'ai plus qu'à ajouter les quelques spécificités s'il y en a.

Quelques soient mes projets, mes bootstrap, initializer et config conservent le même fonctionnement.

Dernière modification par Delprog (22-01-2009 16:02:15)