Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Ca dépend, si des personnes différentes travaillent sur le back et sur le front, ce n'est pas forcément évident
Encore une fois l'organisation dépend de la dimension du projet, de l'équipe de dev et du nombre d'intervenants.
Hors ligne
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
Hors ligne
Encore une fois l'organisation dépend de la dimension du projet, de l'équipe de dev et du nombre d'intervenants.
Bah moi va y en avoir un paquet j'espère, je développe actuellement un (gros) portail mixant site d'actus et réseau social pour musiciens avec des tonnes de fonctionnalités (dont certaines à venir ) donc on compte avoir des "milliers" de visiteurs. Pour l'instant on est 3 sur le dév.
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 !)
Ma méthode n'empèche pas cela je pense, puisque j'ai des parties comme dans ton exemple mais qui ne sont accessible qu'une fois loggé en admin (évidemment me direz-vous )
Et pour la "première fois", y'aura Zend_Tool (actuellement dans l'incubator)
Hors ligne
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 ?
Hors ligne
Salut je n'avais pas vu cette question resté en suspend
justement pas façon de faire un crud ne dépends absolument pas de l'existence supposée d'une base de donnée
mon crud se centralise sur le contrôleur
il demande à ce qu'on définisse des vues respectant certain critères
et un classe modèle respectant un interface
tu peux ton sans aucune difficulté choisir l'implémentation que tu vas faire de cette classe
tu peux choisir d'utiliser Zend_DB_Table ou LDAP mon crud s'en moque royalement.
A+JYT
Hors ligne
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)
Hors ligne