Zend FR

Consultez la FAQ sur le ZF avant de poster une question

Vous n'êtes pas identifié.

#1 26-06-2008 11:53:06

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

[REFLEXION] Construction d'un back-office

Bonjour à toutes et à tous,

Je travaille sur la création d'un back-office suffisamment générique pour pouvoir être réutiliser dans plusieurs projets.

Je voudrais mener avec vous, si vous êtes d'accord smile, une réflexion sur les bonnes pratiques à mettre en place dans le cadre d'un tel développement avec le Zend Framework (évidemment!).

1er point abordé : LE STOCKAGE DE LA CONFIGURATION DU BO
- Comment la gérer ?
Tout mettre en base de données, tout placer dans des fichiers de configurations (XML, INI), un mixe des deux en fonction des données de configuration et de leur importance ?
- Quel est l'impact sur les performances globales du choix d'une méthode de stochage de ces informations ?
- Bien pensé au fait que la configuration peut évoluer avec l'ajout de modules, fonctionnalités, etc. Comment bien anticipé cela ? Est ce que justement l'utilisation de petits fichiers de configurations très spécifiques ne seraient pas la meilleure solution ?

2ème point abordé : LA BDD
Elle doit être suffisamment bien conçue pour pouvoir digérer toute évolution ultérieures (dans des limites raisonnables bien sur smile).
Avez vous des idées sur ce qu'il faut surtout éviter comme écueil ?

3ème point abordé : LA GESTION DE MODULES COMPLEMENTAIRES
Les modules étendent les fonctionnalités du BO. Pour cela, il doivent :
- être installables / désinstallables
- être activables / désactivables
- pouvoir être configurés
- être mis à jour

Je pense qu'un (ou plusieurs) fichier(s) de configuration par module sont nécessaires (bien qu'encore une fois la question se pose de mettre leur configuration en base de données).

Ce sujet évoluera en fonction de l'ajout de point à checker.
Mais dans un premier lieu, j'aimerai savoir si cette discussion présente un intérêt pour vous ou pas du tout (auquel cas je réflexionnerai tout seul dans mon coin smile)

Je sais que certains d'entre vous ont déjà mis en place des BO. Sans dévoiler tout leur travail (évidemment), peuvent ils nous faire un retour d'expérience sur les pièges à éviter auxquels nous sommes tous potentiellement susceptibles de tomber.

Voilà, d'avance merci pour vos retours.

Dernière modification par elkolonel (26-06-2008 12:09:29)

Hors ligne

 

#2 26-06-2008 14:32:35

Mr.MoOx
Administrateur
Lieu: Toulouse
Date d'inscription: 27-03-2007
Messages: 1444
Site web

Re: [REFLEXION] Construction d'un back-office

Personnellement grâce au ACL je ne créer pas de module spécifique pour mes backoffices, je créer uniquement des liens qui apparaissent si l'utilisateurs à des droits ou non, tout comme sur ce forum!
Bien sur un controle via un plugin gérant les acls est effectuer sur chaque page smile

Hors ligne

 

#3 26-06-2008 14:40:24

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Oui, mais donc cela t'oblige à avoir ton back office sous forme monolithique, non modulable, donc pas forcément portable dans d'autres projets, non ?

Hors ligne

 

#4 26-06-2008 14:49:03

Mr.MoOx
Administrateur
Lieu: Toulouse
Date d'inscription: 27-03-2007
Messages: 1444
Site web

Re: [REFLEXION] Construction d'un back-office

Exactement. C'est un choix que j'ai fais. Actuellement j'ai plus l'habitude de faire des classes abstraires (ou dans le genre). Du coup selon mes besoins, je vais de très rapide copier coller que je personnalise spécifiquemenbt à chaque fois.
Récemment j'ai plus travaillé sur de gros projets, donc j'ai pas trop d'interet à faire un système de backoffice "portable" smile
En plus Le ZF va apparament créer un composant pour générer des parties d'admin wink
Donc j'attends!

Hors ligne

 

#5 26-06-2008 15:00:55

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Mr.MoOx a écrit:

Exactement. C'est un choix que j'ai fais. Actuellement j'ai plus l'habitude de faire des classes abstraires (ou dans le genre). Du coup selon mes besoins, je vais de très rapide copier coller que je personnalise spécifiquemenbt à chaque fois.
Récemment j'ai plus travaillé sur de gros projets, donc j'ai pas trop d'interet à faire un système de backoffice "portable" smile
En plus Le ZF va apparament créer un composant pour générer des parties d'admin wink
Donc j'attends!

@ Mr MoOx : Vraiment yikes,  c'est déjà dans les proposals ? Tu as des news ? Quelles specs etc ? Génération auto un peu comme symfony ?

@ Others : d'autres personnes souhaitent soumettre leur expérience sur les back-offices ?

Hors ligne

 

#6 26-06-2008 15:06:56

Mr.MoOx
Administrateur
Lieu: Toulouse
Date d'inscription: 27-03-2007
Messages: 1444
Site web

Re: [REFLEXION] Construction d'un back-office

Hors ligne

 

#7 26-06-2008 15:37:21

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Oui enfin attention tout de même pas de modif depuis mars 2007 neutral
Pas très actif comme projet... Peut on se fier à cela, perso je suis pas sur.

Hors ligne

 

#8 26-06-2008 16:39:18

Roulio
Membre
Lieu: Alsace
Date d'inscription: 20-11-2007
Messages: 137
Site web

Re: [REFLEXION] Construction d'un back-office

Et pourtant le projet est certainement en cours. "Ils en parlent" aussi ici http://www.z-f.fr/forum/viewtopic.php?id=1104

Sinon pour partager un peu de mon expérience pour la création des back-offices, je fais tout sur mesure mais bien sûr il y a certaines fonctions qui sont réutilisables. Les projets sur lesquels je travaille sont tous complètement différents. Si c'est une gestion de parc automobile ça ressemblera jamais complètement à une admin pour la gestion d'un parc informatique... les demandes seront jamais les mêmes pour coder les fonctionnalités

Hors ligne

 

#9 26-06-2008 17:04:15

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Oui c'est vrai j'avais vu également cette discussion, mais qui fait référence au même proposal de 2007.

Ensuite je suis d'accord avec toi que chaque Back Office est censé gérer des choses différentes. Toutefois le Core du Back Office peut être un socle commun, ensuite tu installes les modules dont tu as besoin. Je m'explique :
Le core pourrait se composer (ceci n'est qu'un exemple) :
- d'une gestion de l'affichage du back office (avec ou sans système de template, ce n'est pas le plus important)
- d'un système de gestion des utilisateurs (du back-office et si besoin des utilisateurs du front) : Zend_Auth + Zend_Acl
- d'une partie s'occupant de toute la partie Localization, Internationnalisation (L10N,I18N)
- d'un systeme de gestion de news + rss (on peut supposer que tout les sites ont besoin aujourd'hui d'un systeme de news)
- d'un système crud pour générer dynamiquement les champs administrables couplé à un système de configuration permettant de déterminer quelles tables, quels champs de tables sont à gérer dynamiquement dans le back office, tout cela couplé à Zend_Form
- un système de statistiques
- le système permettant l'installation/désinstallation/activation/désactivation/paramétrages des modules
- etc.

Ensuite pour les parties métiers spécifiques à chaque client, on peut tout imaginer :
- gestion de cv
- gestion de parcs informatiques
- gestion commerciale
- etc.

Mais en pensant bien dès le départ le modèle de données et la structure du backoffice afin qu'il puisse prendre en compte toutes les évolutions.

Je pense justement qu'il ne faut pas tout réinventer à chaque fois, il faut factoriser et capitaliser le code et l'expérience (évidemment ça c'est une version idéale dans un monde où tout le monde il est gentil smile).

Dites moi si ma vision des choses est utopiste ? si elle est irréalisable ? peut être l'investissement en temps de développement d'un tel back office n'est pas rentable ?

Hors ligne

 

#10 26-06-2008 17:55:18

whitespirit
Membre
Date d'inscription: 25-01-2008
Messages: 393

Re: [REFLEXION] Construction d'un back-office

Moi je dis : tout dépends combien de temps tu as ! Ta vision n'est pas utopiste au contraire, dans l'absolu (c'est à dire sans deadline) on devrait tous avoir un truc dans le genre. Moi j'ai commencé à développé ma gestion d'appli en Février (j'en ai profité pour apprendre le ZF par la même occasion smile) et figure toi que je suis loin d'avoir terminé. Bon d'une part parceque je bosse sur plusieurs projets en même temps et d'autre part parceque je dois me former sur le tas (j'ai toujours pas commençé l'ajax arggghh sad).

Ceci dit, toutes les parties que tu as cités sont indépendantes et réutilisable de tes applis, tu as bien raison :

- d'une gestion de l'affichage du back office (avec ou sans système de template, ce n'est pas le plus important)
- d'un système de gestion des utilisateurs (du back-office et si besoin des utilisateurs du front) : Zend_Auth + Zend_Acl
- d'une partie s'occupant de toute la partie Localization, Internationnalisation (L10N,I18N)
- d'un systeme de gestion de news + rss (on peut supposer que tout les sites ont besoin aujourd'hui d'un systeme de news)
- d'un système crud pour générer dynamiquement les champs administrables couplé à un système de configuration permettant de déterminer quelles tables, quels champs de tables sont à gérer dynamiquement dans le back office, tout cela couplé à Zend_Form

Après faut avoir le temps de tout bien faire.

le système permettant l'installation/désinstallation/activation/désactivation/paramétrages des modules

ca c'est interessant tiens, un de ces quatre je développerai des modules qui vont dans ce sens, d'ailleurs je m'inspirerai d'un CMS qui utilise une telle gestion de module (Joomla).

Je pense que si t'as un gros projet, t'as plutôt intérêt de développer dans ce sens. Encore une fois tout dépend que tu as devant toi, et identifier les priorités.

PS: mettre un système de CRUD en place n'est pas super compliqué, par contre faut avoir une bonne charte graphique, et avoir bien décomposé ton template en zone indépendantes.

PS2 :

Je pense justement qu'il ne faut pas tout réinventer à chaque fois, il faut factoriser et capitaliser le code et l'expérience

n'oublie pas qu'il existe des logiciels openSource pour la gestion commercial (SugarCrm, VTiger, Dolibaar, etc.), pour la gestion de parcs informatiques (Glpi, OCS..), pour la gestion de document (Maarch, Alfresco, etc...). En clair, comme tu l'as bien dit, il ne faut pas réinventer la roue si on a des besoins "génériques".

Dernière modification par whitespirit (26-06-2008 17:57:16)

Hors ligne

 

#11 26-06-2008 21:27:32

2mx
Membre
Lieu: Grenoble
Date d'inscription: 06-08-2007
Messages: 125

Re: [REFLEXION] Construction d'un back-office

elkolonel a écrit:

Je voudrais mener avec vous, si vous êtes d'accord smile, une réflexion sur les bonnes pratiques à mettre en place dans le cadre d'un tel développement avec le Zend Framework (évidemment!).

Salut,

C’est un sujet qui m’intéresse bien, personnellement je travail comme tu le décris : j’ai une structure générique dans la quel je viens « pluger » des modules.

J’utilise la structure modulaire du ZF et chaque module contient à la fois la partie frontOffice et la partie backOffice, plus son fichier de configuration, sa config acl pour gérer les droits d’accès, ses fichiers de traductions, ces models et son fichier SQL pour générer les tables dans la BDD (à supprimer avant mise en ligne). La structure ressemble à ça :

/nommodule
    /config
    /controllers
    /languages
    /models
    /views

Les modules sont donc complètement portables d’une appli à l’autre (dans la mesure où elle est basée sur le même système)

Ensuite j’utilise 2 fichiers de bootstap un à la racine et un dans un répertoire admin. Les 2 font appel à la même classe de bootstrap et lui passe une série d’arguments notamment le thème à utiliser.

J’utilise Zend_Layout qui charge un thème différent en fonction que je suis en front ou en back. Pour la partie backoffice peut importe le projet, j’utilise toujours le même thème. Donc sur des modules déjà développés je n’ai rien à faire sur la partie back et du cosmétique sur la partie front. Si je suis sur un projet de type intra ou extranet dans ce cas il n’y a pas d’admin.

La plupart des administrations de module sont de type CRUD. J’utilise donc un contrôleur CRUD générique. Pour lister les enregistrements j’ai un Data Grid qui me permet de trier et de filtrer les données. Pour les formulaires j’ai un générateur de formulaire qui me génère le code que je copie colle par la suite.

Pour aller encore plus vite j’ai un étendu Zend_Db_Table pour qu’il prenne en charge de façon transparente le classement des enregistrements et les structures avec table i18n.

Pour fonctionner il faut au minimum les modules CORE à savoir : default (qui fait auth, error et dashboard), users et contacts. Plus le bootstrap et son fichier de config. Ensuite j’installe ou développe les modules dont j’ai besoin.

@+

Dernière modification par 2mx (27-06-2008 09:27:32)

Hors ligne

 

#12 26-06-2008 21:36:47

Mr.MoOx
Administrateur
Lieu: Toulouse
Date d'inscription: 27-03-2007
Messages: 1444
Site web

Re: [REFLEXION] Construction d'un back-office

n'oublie pas qu'il existe des logiciels openSource pour la gestion commercial (SugarCrm, VTiger, Dolibaar, etc.), pour la gestion de parcs informatiques (Glpi, OCS..), pour la gestion de document (Maarch, Alfresco, etc...). En clair, comme tu l'as bien dit, il ne faut pas réinventer la roue si on a des besoins "génériques".

Après il faut voir le code derrière (et la communauté) pour penser à la maintenance et l'évolutivité du produit final. Ca pour moi c'est très important car par les experiences de ma famille (mon père et ingénieur en informatique et mon grand frère est développer) je sais que à long terme (même à moyen :p ) ça paye wink
Et y'a aussi le plaisir de créer de ses propres mains avec le ZF!

Hors ligne

 

#13 27-06-2008 07:06:14

whitespirit
Membre
Date d'inscription: 25-01-2008
Messages: 393

Re: [REFLEXION] Construction d'un back-office

A 100% d'accord avec toi Mr.MoOx, c'est pour cette raison que j'ai écris ça dans un PS. Par contre, il est bon de savoir que aujourd'hui, le code que l'on trouve dans les nouveaux cms, crm, ged, etc. écrit en php est clean => vive php5 et l'objet ! Le truc à savoir c'est que derrière ces gros outils OpenSource il y'a des équipes dés fois volumineuse (ex:sugarCRM) ou des équipes indiennes/chinoises (ex: VTiger, donc des ingénieurs de talent  payés à 500€ par mois). Le problème que je rencontre est que je suis toujours en équipe réduite (1,2 ou 3 mais au final je suis le principal développeur), la conséquence est simple : j'ai une deadline à respecter sinon le client ne paie pas et la boite dans laquelle je suis coule et je pointe au Assedic ! Bref, choisir un OpenSource pour une gestion commerciale ou pour réaliser un site internet (vitrine, blog, presse) est nettement plus conseillé que de développer sois même.

Ceci dit, "Et y'a aussi le plaisir de créer de ses propres mains avec le ZF!" smile !!!!!!!

Dernière modification par whitespirit (27-06-2008 07:14:49)

Hors ligne

 

#14 27-06-2008 08:34:46

Roulio
Membre
Lieu: Alsace
Date d'inscription: 20-11-2007
Messages: 137
Site web

Re: [REFLEXION] Construction d'un back-office

J'ai une petite question par rapport à la table 'users', tu l'utilise pour n'importe quel type d'utilisateur qui doit se loguer sur le site ? Exemple on pourrait trouver dedans pour un même site : les admins, les modos, les utilisateurs pour admin A, les utilisateurs pour admin B ?

Hors ligne

 

#15 27-06-2008 09:22:33

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

2mx a écrit:

C’est un sujet qui m’intéresse bien, personnellement je travail comme tu le décris : j’ai une structure générique dans la quel je viens « pluger » des modules.

J’utilise la structure modulaire du ZF et chaque module contient à la vois la partie frontOffice et la partie backOffice, plus son fichier de configuration, sa config acl pour gérer les droits d’accès, ses fichiers de traductions, ces models et son fichier SQL pour générer les tables dans la BDD (à supprimer avant mise en ligne). La structure ressemble à ça :

/nommodule
    /config
    /controllers
    /languages
    /models
    /views

Les modules sont donc complètement portables d’une appli à l’autre (dans la mesure où elle est basée sur le même système)

Donc si je comprends bien, j'imagine que tes modules se situent au même niveau dans l'arborescence que le module principal de back-office et de front-office. Ce que je veux dire c'est qu'au niveau de l'arborescence ils ne sont pas situés sous le répertoire back-office ? Comment gères tu les url associées ?

La plupart des administrations de module sont de type CRUD. J’utilise un donc un contrôleur CRUD générique. Pour lister les enregistrements j’ai un Data Grid qui me permet de trier et de filtrer les données. Pour les formulaires j’ai un générateur de formulaire qui me génère le code que je copie colle par la suite.

Est il possible d'avoir un peu plus de détail sur cette partie CRUD sans rentrer dans les secrets de ton BO évidemment... smile

Pour aller encore plus vite j’ai un étendu Zend_Db_Table pour qu’il prenne en charge de façon transparente le classement des enregistrements et les structures avec table i18n.

C'est à dire ? Pas sur d'avoir bien saisi ...


Pour fonctionner il faut au minimum les modules CORE à savoir : default (qui fait auth, error et dashboard), users et contacts. Plus le bootstrap et son fichier de config. Ensuite j’installe ou développe les modules dont j’ai besoin.

@+

Merci en tout cas pour ce bon retour d'expérience...

Hors ligne

 

#16 27-06-2008 09:29:52

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Roulio a écrit:

J'ai une petite question par rapport à la table 'users', tu l'utilise pour n'importe quel type d'utilisateur qui doit se loguer sur le site ? Exemple on pourrait trouver dedans pour un même site : les admins, les modos, les utilisateurs pour admin A, les utilisateurs pour admin B ?

C'est un point assez important où effectivement on peut se poser la question.
Cela dépend peut-être un peu de la volumétrie de chaque catégorie d'utilisateurs et de leurs 'profils'.

Si tu as une équipe réduite "d'admin" (personnes ayant accès au back-office de façon totale ou partielle), il n'est pas forcément nécessaire d'avoir une table dédiée pour eux. Sauf, si las champs les concernant sont trop différents des champs concernant les utilisateurs.

Personnellement, j'opterai pour une table dédié 'utilisateurs' et une table dédié 'administrateurs', pour qu'il n'y ait pas mélange des genres. La structure Core de l'application n'est pas ainsi perturbée ou remise en cause à chaque développement. Après c'est peut-être une lourdeur non nécessaire.

Je n'ai pas encore trop utilisé ACL, donc je parle avec un manque de vision. Peut-être Mr.MoOx pourra nous endire plus sur les capacités d'ACL à gérer les différents profils d'utilisateurs et sur la nécessité ou pas d'avoir une table dédiée par GRANDE catégorie d'utilisateur....

Mr.MoOx, je te cède la parole smile

Hors ligne

 

#17 27-06-2008 10:01:21

Mr.MoOx
Administrateur
Lieu: Toulouse
Date d'inscription: 27-03-2007
Messages: 1444
Site web

Re: [REFLEXION] Construction d'un back-office

Ben moi quand je peux, je met simplement un table user avec un champ role,qui n'est rien de plus qu'un int qui correspond à un rôle que je transforme en rôle pour mes ACLs. Tout simplement.
Après je ne suis pas un expèrs en ACL, mais cette solution ne m'a encore jamais posé de problèmes smile

Hors ligne

 

#18 27-06-2008 10:43:56

Roulio
Membre
Lieu: Alsace
Date d'inscription: 20-11-2007
Messages: 137
Site web

Re: [REFLEXION] Construction d'un back-office

Ok ça paraît logique pour la séparation des types d'utilisateurs dans la DB.

Cette discussion est intéressante, et suscite pleins de questions smile Ca permet également à des personnes moins expérimenté (comme moi) de découvrir des nouvelles techniques. a+

Hors ligne

 

#19 27-06-2008 18:45:35

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Et si nous parlions un peu de la base de données du Back-Office ?

Je sollicite un retour d'expérience des 'expérimentés du BO' smile sur les points suivants :
- nombre de tables, volumétrie de données
- optimisation des requêtes
- benchmarking sur temps de réponses des requêtes complexes
- pièges à éviter
- qu'est ce qu'il vaut mieux sortir de la base de données (pour placer par exemple dans des fichiers de conf)
- scaffolding
- interaction des modules du BO avec la base de données (installation, suppression, activation, configuration, désactivation d'un module)
- tout autre notion dont vous souhaitez nous remonter votre expérience

Voilà, à vos claviers, si cela vous dit wink !

PS : bon week-end à tous !!!

Hors ligne

 

#20 28-06-2008 06:59:25

whitespirit
Membre
Date d'inscription: 25-01-2008
Messages: 393

Re: [REFLEXION] Construction d'un back-office

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" ??

Dernière modification par whitespirit (28-06-2008 07:02:21)

Hors ligne

 

#21 28-06-2008 13:42:08

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Pour moi un module c'est, comme je l'ai expliqué dans le post d'introduction :
- un bloc autonome permettant de rajouter au core BO des fonctionnalités spécifiques métiers ou spécifique client
- il peut être réutilisable ailleurs
- il peut difficilement être intégré nativement au core car la spécifité de son emploi est lié à l'aspect métier
- en fait il est là pour étendre les fonctionnalités du BO et apporter (ou pas) des fonctionnalités dans la partie front office (module recrutement par exemple, en BO toute la gestion de candidat et cv et en FO uniquement les informations à présenter...).
Voir d'ailleurs la vision intéressant de 2mx sur le sujet un peu plus haut dans le post.

Merci en tout cas pour ton retour d'expérience très intéressant.

Cordialement,

Hors ligne

 

#22 30-06-2008 09:38:21

2mx
Membre
Lieu: Grenoble
Date d'inscription: 06-08-2007
Messages: 125

Re: [REFLEXION] Construction d'un back-office

elkolonel a écrit:

Donc si je comprends bien, j'imagine que tes modules se situent au même niveau dans l'arborescence que le module principal de back-office et de front-office. Ce que je veux dire c'est qu'au niveau de l'arborescence ils ne sont pas situés sous le répertoire back-office ? Comment gères tu les url associées ?

En fait je n'ai pas de module spécifique front ou back. Mon système est tout simple, j'ai une class de bootstrap et l'ensemble de mes modules.

/application
    /config
        /config.ini
    /languages
        /errors
        /messages
    /layouts
        /admin
        /default
    /modules
        /contacts
        /default
        ...
        /users
    /public
        /admin
            index.php
            .htacess
        /themes
            /_common
                /javascript
            /admin
                /css
                /images
                /javascript
            /default
                /css
                /images
                /javascript
        index.php
        .htacess
Bootstrap.php

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.

Ensuite rien empêche d'avoir un module system / backoffice qui permettrai de paramétrer et de monitorer l'application (à la zf panel http://www.z-f.fr/forum/viewtopic.php?id=641).

elkolonel a écrit:

Est il possible d'avoir un peu plus de détail sur cette partie CRUD sans rentrer dans les secrets de ton BO évidemment... smile

plus d'infos ici :
http://www.z-f.fr/forum/viewtopic.php?id=577
http://www.z-f.fr/forum/viewtopic.php?id=830

2mx a écrit:

Pour aller encore plus vite j’ai un étendu Zend_Db_Table pour qu’il prenne en charge de façon transparente le classement des enregistrements et les structures avec table i18n.

elkolonel a écrit:

C'est à dire ? Pas sur d'avoir bien saisi ...

Désolé c'était un peu à l'arrache car je n'ai pas beaucoup de temps en ce moment. Pour faire simple : pour les applis multilingue, en générale on utilise 2 tables dont une contenant tout les champs devant être traduits. Il y a moyen avec Zend_Db_Table de traiter ces 2 tables comme 1 seule.

Pour le classement des enregistrement http://www.symfony-project.org/cookbook/1_0/en/sortable

Dernière modification par 2mx (30-06-2008 09:43:05)

Hors ligne

 

#23 13-07-2008 11:41:40

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Merci Laurent, alors maintenant peut on aller plus loin. Peux t-on faire ceci :

Code:

library
   Zend
   MaLibrairie
   ...
application
   default
      controllers
      models
      views
   backoffice
      modules
         dashboard
            controllers
            models
            views
         news
            controllers
            models
            views
         newsletters
            controllers
            models
            views
         medias
            controllers
            models
            views
htdocs
   index.php
   /public
       images
       css
etc...

Pensez vous que cela soit possible en adaptant correctement son bootstrap ??

Cordialement,

Hors ligne

 

#24 13-07-2008 16:10:35

elkolonel
Administrateur
Lieu: Grasse
Date d'inscription: 18-12-2007
Messages: 299
Site web

Re: [REFLEXION] Construction d'un back-office

Mr.MoOx a écrit:

Ben moi quand je peux, je met simplement un table user avec un champ role,qui n'est rien de plus qu'un int qui correspond à un rôle que je transforme en rôle pour mes ACLs. Tout simplement.
Après je ne suis pas un expèrs en ACL, mais cette solution ne m'a encore jamais posé de problèmes smile

Salut M. MoOx, je reviens un peu sur le sujet ACL. Ta solution marche sans doute très bien mais quid si tu souhaites donner une palette d'accès à un utilisateur. exemple :
- lecture, ecriture sur les news
- lecture seule sur les médias
- consultation des statistiques sur les newsletters

News, Medias et Newsletter étant des modules du BO.
Il serait peut être intéressant de prévoir une table de droit. Ce qui permettrait à chaque utilisateur d'avoir plusieurs droits en fonction des modules qu'il a le droit d'utiliser.

Qu'en penses tu ? Qu'en pensez vous ?

Cordialement,

Hors ligne

 

#25 15-07-2008 10:13:57

Azema
Membre
Lieu: Paris
Date d'inscription: 26-09-2007
Messages: 51
Site web

Re: [REFLEXION] Construction d'un back-office

Salut à tous,

Je pense qu'il est plus intéressant de créer plusieurs rôles différents qui permettent d'accéder ou non à des ressources et ensuite distribuer les rôles à chaque utilisateurs du système. Cela me parait moins lourd à gérer.

Cordialement, Azema.

Hors ligne

 

Pied de page des forums

Propulsé par PunBB
© Copyright 2002–2005 Rickard Andersson
Traduction par punbb.fr

Graphisme réalisé par l'agence Rodolphe Eveilleau
Développement par Kitpages