Zend FR

Avez-vous pensé à ne pas faire de "back office" séparé en utilisant judicieusement les ACLs?

oui j'ai deja une système "d'édition rapise" on va dire. (je trouve ça plus ou moins obligatoire, c'est bien plus rapide pour ajouter/editer une news)

Mais le projet doit être plus maniable que ça, une légère sorte de CMS, ajout de page static, gestion du menu, modification des ACL (simple) ...(projet sympa, mais complet !)

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

oui mais pas la première fois

whitespirit a écrit:

Pour une appli basique de type CRM/CMS je tourne autour de 50 tables. En ce qui concerne l'optimisation de la bd, je ne suis pas un as, mais c'est plus de l'optimisation de MySQL (création d'index, jointure, procédure stockées, etc.) que du ZF.

Pour ma part, les erreurs fatales que j'ai faites au départ sont :

- ne pas utiliser de jointure à la Sekaijin : sur son blog il a mis une classe Fast_Db_Table qui m'a largement facilité la gestion des jointures : du coup je n'utilise que rarement les fonctions FindParentRow (un truc comme ça) sauf pour simuler une jointure qui n'existe pas.

- recharger toutes mes requêtes d'acl et menu sur chaque page à chaque fois dans le bootstrap : j'attendais 10secondes par pages. Maintenant tout est en session/cache

- j'essaie de mettre le minimum d'information possible dans des fichiers de conf afin que tout soit facilement paramétrable depuis une interface web. Mais bon, c'est que ça me saoule de faire de 'vi' quand je suis sur un serveur dédié (ok, c'est nul comme argument).

- Ha, une erreur un peu 'débile' que j'avais faite : oublier les contraintes onCascade lors de la création de ma db, du coup, je réécrivais une requêtes pour les deleteOnCascade

- Autre erreur, créer les requêtes via l'objet Zend_db et non Zend_Table (utiliser table->select()->where()->order() facilite vraiment, vraiment la vie pour construire des requêtes dynamiques)

Par contre, dans ma gestion, ce dont je suis content car c'est fait : une gestion complète des Acl & Auth dynamique, donc tout stocké dans la bd (un type d'utilisateur va pouvoir exécuter une Action ou non disponible dans un Module)

PS: qu'est ce que tu appelles "modules" ??

J'aurais du relire tout ces conseils avant de me lancer dans le crud à la sekajin (ceci n'est pas une critique)

Le crud façon sekajin est très bien pour un simple back office, mais dès qu'il faut créer des jointures, et créer des requêtes dynamique, et bien on voit vite les limites de Zend_Db_Table ...

Qu'en pensez vous ?

Bonjour,

Après lecture du post fil je me permets de rebondir sur quelques points (pas d'idées, des questions plutôt...).
Voici donc lesquels :

whitespirit a écrit:

Par contre, dans ma gestion, ce dont je suis content car c'est fait : une gestion complète des Acl & Auth dynamique, donc tout stocké dans la bd (un type d'utilisateur va pouvoir exécuter une Action ou non disponible dans un Module)

Ici les ACL restreignent l'accès à des actions. Mais à quel type d'actions ? Les actions du Zend_Controller_Action (méthodes <name>Action) ?

Si c'est bien cela, j'ai du mal à imaginer la gestion dynamique d'ACL conditionnelles (avec des assertions), ou le besoin de vérifier un privilège ailleurs que sur une action...

Quelqu'un saurais étayer un peu la manière dont cela a pu être implémenté ?

2mx a écrit:

Ce qui glu l'ensemble c'est le layout avec son menu. En générale la home du backoffice est un tableau de bord (/defaut/dashboard/index) qui donne une vue d'ensemble. Les infos sont affichées à partir de partials appartenant à chacun des modules. Idem pour le front.

Je rebondis sur ce point pour tenter de comprendre la meilleur manière de faire communiquer une page (de /default) avec une vue (ou contrôleur, ou aide, ...) d'un autre module.

En ce qui concerne le partial des infos du module "contacts"  (/modules/contacts/) dont il est question, cela signifie que dans la vue views/scripts/dashboard/index est fait un $this->partial('<path/file>.phtml, 'contacts') j'imagine.

Si c'est ainsi quelle est la meilleur emanière de gérer les données métiers à utiliser dans la vue ?
- récupérer dans le controller /dashboard les données concernant les "contacts" et de les stocker dans une propriété de vue ($this->view->data = <data>) pour les passer ensuite en paramètre de $this->partial(,,$data) dans le fichier de vue du /dashboard/index ?
- récupérer dans le controller /dashboard les données concernant les "contacts" en appelant une aide d'action situées dans le module /contacts ? ou en appelant une action d'un contrôleur d'action du module /contacts ?
- même cas qu'au dessus mais cette fois c'est le contrôleur de /module/contacts/ ou l'aide d'action qui stocke dans $this->view les données à afficher, et côté vue "/dashboard/index" on appelle une aide de vue du modules /contact/ pour injecter le contenu ?
- récupérer les données de "contacts" au sein même de la vue appelée par le partial ? (probablement le pire des cas enviageables !)
- autre manière plus efficace dans une architecture modulaire ?

Merci,


Très intéressant de voir toutes les approches différentes concernant la mise en place d'un BO. Je tâcherais d'utiliser la méthode qui semble la plus flexible.

Depuis ces discussions, certains d'entre vous ont-ils rencontré des contraintes inattendues avec la mise en application qu'ils ont exposé ici, ou bien même changé de méthode pour quelque chose de plus "pertinent" à leur yeux ?

Dernière modification par Eureka (27-08-2009 19:43:55)