[Conception] Site modulaire

Bonjour,

Je suis en train de redévelopper une sorte de panneau d'administration pour site web. Le principe est simple : le site a une zone admin, où les utilisateurs peuvent accéder, et de laquelle ils peuvent gérer divers "modules" : newser, faq, utilisateurs, etc...

Jusqu'à maintenant, c'était fait de manière partiellement modulaire, dans le sens où chaque "module" avait un fichier principal (par exemple news.php), qui utilise un composant global pour l'authentification (include auth.inc.php) et qui sinon fait tout le reste "dans son coin". Donc pour ajouter un module, il faut juste modifier le script d'authentification pour qu'il gère les droits relatifs à ce module, ainsi que le module de gestion des utilisateurs, afin à nouveau d'intégrer la gestion des droits à ce nouveau module. Pour l'intégration au "frontend" du site, c'est fait à la main.

J'aimerais maintenant faire quelque chose d'encore plus simple : un dossier "modules", ou extensions, dans lequel on dépose simplement les modules que l'on souhaite utiliser. Ensuite, les modules sont visibles depuis l'admin mais pas encore installés. Un clic sur un lien installe le module (et effectue les traitement spécifiques au modules : création de tables, dossiers, etc...) et c'est bon !

La gestion des droits des utilisateurs se fait aussi automatiquement via un module qui gère le tout, et l'authentification est gérée par un gros composant principal, qui "dirige" tous les modules et leur donne accès à la DB, aux fichiers de config, aux données sur l'utilisateur (droits, etc...).

J'ai quelques idées sur comment faire ça (j'ai un peu regardé divers projets qui me plaisaient et/ou qui ont l'air pas trop mal structurés, comme phpBB, punBB, vanillla, Joomla, etc...) : une classe principale qui s'occupe, comme décrit plus haut, des accès à la DB et de l'authentification, et les modules qui eux implémentent une interface.

Que pensez-vous de cette approche ? Avez-vous de la lecture à me conseiller, ou des conseils à me donner ?

J'ai quelques soucis avec cette approche : je ne sais pas comment gérer les fichiers de configuration (des includes ? des fichiers xml à loader ?), ni comment permettre aux modules de "travailler" comme ils veulent tout en ayant accès aux attributs de la "grosse classe" qui gère tout, c'est-à-dire comment faire le lien entre le core et les modules ?

De plus, j'aimerais bien utiliser un système de templates, afin de séparer le plus possible le traitement de l'affichage, et aussi permettre de changer de layout facilement (thèmes ?). Le problème, c'est que chaque module a ses propres templates, mais aussi devra utiliser des templates "globaux" pour les headers/footers, afin d'assurer une certaine cohérence dans la zone admin. J'ai de la peine à m'y retrouver, surtout avec les différentes paths relatifs et/ou absolus, etc... !

Bref, grosse tartine, grosse ambition aussi, mais ça me tient à coeur ;) ! Je pense que ça doit être réalisable ! Et j'attends vos commentaires !

Bonjour,

Je pense qu'il serait plus simple de partir de l'existant, il y certainement un CMS pour votre problème. Regardé à www.opensourcecms.com.

Si vous voulez vraiment le faire vous même, vous pouvez envisager d'utiliser les librairies existante comme.

http://smarty.php.net/
http://www.cakephp.org/
http://www.symfony-project.com/

Bonjour,

Il est vrai que l'utilisation d'un CMS existant est envisageable (Joomla!, Typo3, ?), mais je préférerais la flexibilité que m'apporterai la connaissance intime et profonde de l'outil que j'utilise, d'où l'envie de le développer moi-même :mrgreen:...

Par contre, l'utilisation d'une ou plusieurs librairies externes pour m'y aider était prévue. J'utilise déjà le moteur de templates de la phplib (je viens de voir qu'il y avait peut-être d'autres modules de cette phplib qui pourrait m'intéresser...), par exemple !

Le deuxième lien que vous m'avez donné me semble un bon point de départ. Le fait d'utiliser un framework éprouvé et relativement populaire apportera certainement une sécurité et une robustesse bien supérieure à celle obtenue à l'aide d'un framework totalement maison, non ?

De plus, la communauté de ce CakePHP m'a l'air passablement active et productive ;) ? Quelqu'un a-t-il une expérience avec ce framework ?

Merci en tous cas !

L'avantage de ce qui est fait maison, c'est que la construction n'est connu que de la personne qui le fait ...
Ainsi, si défaut existe, une librairie public aura plus de tentative d'Hacking, qu'un script que tu aura fait toi même ...

De plus, comme tout, ce qui est compris, peut être reproduit. Si tu n'es pas capable de reproduire un script tel que phplib (par exemple), c'est que tu ne l'as pas comprit ... (comme si c'était évidant ^_^) Or utiliser quelque chose qu'on ne comprend pas ... C'est pas super intéressant non ?

C'est pour ça que je préfère, quitte à faire moins bien, mes propres scripts, à ceux pré-existant.

Et puis, tu programmes pour te faire plaisir ? (>_<) C'est toujours mieux de se dire : J'ai tout compris (et tout fait :oops: ) que : Cool ça fonctionne ... j'espère qu'il n'y aura pas de problème sinon j'suis mal ...

En tout cas, bonne chance à toi :).

P.s : Si j'ai un conseil, c'est celui de tournée ton clavier 7 fois dans ta bouche avant de commencer à coder quelque chose ^_^. Il faut être sur de ce que tu souhaites faire.

Citation:

---

Envoyé par SpiritOfDoc

L'avantage de ce qui est fait maison, c'est que la construction n'est connu que de la personne qui le fait ...
Ainsi, si défaut existe, une librairie public aura plus de tentative d'Hacking, qu'un script que tu aura fait toi même ...

---

Je suis d'accord... Mais disons qu'utiliser un framework bas niveau style Cake est difficilement visible du point de vue de l'utilisateur, donc un potentiel hacker aura de la peine à savoir que j'utilise tel script pour en exploiter une faille. Par contre, pour un CMS, c'est autre chose...

Citation:

---

Envoyé par SpiritOfDoc

De plus, comme tout, ce qui est compris, peut être reproduit. Si tu n'es pas capable de reproduire un script tel que phplib (par exemple), c'est que tu ne l'as pas comprit ... (comme si c'était évidant ^_^) Or utiliser quelque chose qu'on ne comprend pas ... C'est pas super intéressant non ?

C'est pour ça que je préfère, quitte à faire moins bien, mes propres scripts, à ceux pré-existant.

---

Je ne suis pas tout à fait d'accord. Je peux utiliser quelque chose que je n'ai pas fait tout en ayant une bonne idée du fonctionnement général (même si je suis d'accord que je n'aurais pas la même compréhension que si je l'avais fait moi-même...). De plus, pourquoi ré-inventer la roue ? Je n'ai quand même pas le temps de TOUT refaire ! Même si l'envie m'en dirait...

J'ai par exemple développé un forum (assez basique), afin de voir comment ça fonctionnait, et pour mon plaisir, mais ce n'est pas pour autant que je l'utilise actuellement. Des scripts comme phpBB ou punBB offrent quand même bien plus de fonctionnalités ! Le nombre de gens qui y travaillent aide à avancer plus vite ;) !

Citation:

---

Envoyé par SpiritOfDoc

Et puis, tu programmes pour te faire plaisir ? (>_<) C'est toujours mieux de se dire : J'ai tout compris (et tout fait :oops: ) que : Cool ça fonctionne ... j'espère qu'il n'y aura pas de problème sinon j'suis mal ...

---

Programmer est un plaisir, mais en l'occurence ce que je veux développer, c'est pour la petite boîte d'hébergement que j'ai avec des potes... Donc il faut aussi que ce soit fiable ! Et aussi fonctionnel assez rapidement, d'où la volonté d'utiliser des frameworks existants comme base pour accélérer un peu le travail :roll:...

Citation:

---

Envoyé par SpiritOfDoc

P.s : Si j'ai un conseil, c'est celui de tournée ton clavier 7 fois dans ta bouche avant de commencer à coder quelque chose ^_^. Il faut être sur de ce que tu souhaites faire.

---

Je suis d'accord, il ne faut pas se lancer dans la prog tête baissée ;) ! C'est bien pour ça que je suis sur ce forum à discuter ! Je cherche des avis/conseils sur la conception d'un site de manière modulaire, afin de voir un peu comment je pourrais faire, et quels sont les outils que je pourrais utiliser. Ensuite, je commencerai à coder ;) !

Merci pour ton intervention en tous cas !

Pédagogiquement je m'orienterais vers la conception "from scratch" afin de monter en compétence dans plusieurs domaines : analyse, conception, prototypage, tests unitaires, ... et php.
Businessement parlant (aka si des sous/temps sont en jeux derrière) je m'orienterais plutôt vers des framework prêt à l'emploi, avec une préfezrence vers symphony.

Sinon pour répondre à une de tes questions, une solution et l'utilisation d'évenements. Chaque modules écoutent une série d'évenements, et le coeur de l'appli lance des évenements au fil de son execution. Seuls les modules qui écoutent un évenement particulier sont réveillés.
Prenons un exemple : l'interface d'administration des modules. Tu veux pouvoir afficher la liste des modules installés et leur description. Normalement seul le module connait sa propre description.
Ainsi dans le coeur de l'appli :

Code:

---

send_event('afficher_info_module');

---

Et pour chaque module :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

class Forum extends Module { function afficher_info_module() { echo '<h2>Forum</h2>'; echo '<p>Ce module est un forum...</p>'; } ... }   class Agenda extends Module { function afficher_info_module() { echo '<h2>Agenda</h2>'; echo '<em>Version Beta</em>'; echo '<p>Ce module est un agenda...</p>'; } ... }

---

L'idée est la suivante : l'application ignore tout de comment fonctionne les modules, qu'est ce qui les compose. Elle lance seulement quelques évenements qui ne réveilleront que les modules qui sont concernés.

Je suis d'accord avec l'aspect pédagogique... C'était bien mon intention initiale que de commencer "from scratch", c'est juste que j'ai quelques soucis sur la manière d'aborder le problème ;) ! Mais, avec votre aide éclairée, j'en suis sûr, je vais arriver à coder quelque chose de potable ;) ! Comme je n'ai pas d'impératif de temps, je vais penser à mon épanouissement personnel et tout faire moi-même (à part peut-être le système de templates) !

Mr. N., merci pour ton explication. Ca rejoint un peu ce que ce je pensais au départ, à savoir une interface pour les modules, et l'appli principale qui appellera certaines méthodes à certains moments, sachant quelle action cela provoquera mais ignorant tout de la manière dont ce sera fait.

Pourrais-tu développer le concept d'événements, auquel je n'avais pas pensé ? Comment peut-on gérer ça ? Par exemple, certains modules auront des événements spécifiques à eux-même (genre "add_user" pour le module de gestion des utilisateurs). Comment s'enregistrent-ils auprès de l'application ?

Je verrais quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Core { private $eventHandlers = array();   function registerEventHandler($event, $module) { if (!array_key_exists($event, $eventHandlers)) $eventHandlers[$event] = array();   array_push($eventHandlers[$event], $module); }   function fireEvent($event) { foreach ($m in $eventHandlers[$event]) $m->eventFired($event); } }

---

Mais je ne sais pas si cette manière de faire est adaptée à mon problème ? Qu'est-ce qu'on peut considérer comme un événement ? La transmission d'un formulaire ? Le clic sur un bouton ?

En fait, je pense voir comment faire, et surtout comment utiliser cette notion d'événements pour permettre aux modules d'utiliser le template global et d'afficher leur propre contenu à un certain endroit ;) ! Je peux imaginer des événements "prepare_menu", "prepare_page", etc...

Merci ! La discussion reste ouverte, si vous avez d'autres conseils/réactions :mrgreen:....

Citation:

---

Envoyé par Wookai

je vais penser à mon épanouissement personnel et tout faire moi-même (à part peut-être le système de templates) !

---

A savoir que tu apprends beaucoup en faisant par toi même (à condition de faire des erreurs sinon tu retires rien de ton expérience :D ) mais aussi beaucoup en étudiant le code des autres
Quand aux templates je te suggère de lire cet article :
http://www.massassi.com/php/articles/template_engines/

Citation:

---

Comment peut-on gérer ça ? Par exemple, certains modules auront des événements spécifiques à eux-même (genre "add_user" pour le module de gestion des utilisateurs).

---

Il faut dans la mesure du possible éviter d'avoir des évenements spécifiques à un module particulier. Le but étant d'avoir le minimum de couplage entre les différentes parties (et c'est le but d'une architecture modulaire).
Exemple, au lieu d'avoir l'évenement 'display_forum_parts_on_front_page' on aura plutot 'front_page' afin que d'autres modules puisse écouter cet évenement. Bien sur un module risque d'avoir besoin à un moment donner un évennement bien particulier... alors il faut se mettre dans l'idée quand on implémente cet évenement du côté de coeur de l'appli qu'il pourra être réutilisé par un autre module dans le futur et le rendre le plus générique possible.

Citation:

---

Comment s'enregistrent-ils auprès de l'application ?

Je verrais quelque chose du genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

class Core { private $eventHandlers = array();   function registerEventHandler($event, $module) { if (!array_key_exists($event, $eventHandlers)) $eventHandlers[$event] = array();   array_push($eventHandlers[$event], $module); }   function fireEvent($event) { foreach ($m in $eventHandlers[$event]) $m->eventFired($event); } }

---

---

Tout à fait !

Citation:

---

Mais je ne sais pas si cette manière de faire est adaptée à mon problème ?

---

Ca je ne peut répondre à ta place. C'est une solution possible que je trouve élégante. Ca respecte le principe d'ouverture/fermeture : le code est ouvert aux extensions mais fermé aux modifications.

Citation:

---

Qu'est-ce qu'on peut considérer comme un événement ? La transmission d'un formulaire ? Le clic sur un bouton ?

---

non le clic sur un bouton est un évenement du coté client (qui peut devenir un evenement coté serveur avec le framework prado si je me souvient bien...)
Il faut raisonner à un plus haut niveau.

Citation:

---

En fait, je pense voir comment faire, et surtout comment utiliser cette notion d'événements pour permettre aux modules d'utiliser le template global et d'afficher leur propre contenu à un certain endroit ;) ! Je peux imaginer des événements "prepare_menu", "prepare_page", etc...

---

Tout à fait. Par exemple si je revient à mon exemple d'évenement 'front_page', cet evenement autoriserait à tous les modules qui l'écoute d'afficher des infos en page d'accueil : le forum afficherait les 10 derniers messages, l'agenda afficherait les évenements qui auront cours dans les 7 prochains jours, les news afficheront les dernieres news, ....


Pour revenir sur la meilleur optique, le mieux selon moi si on a énormément de temps devant soi, c'est de travailler sur les principaux framework du marché, disont prado, zend et symphony, de voir leur points faibles et leurs points forts et d'en tirer le meilleur en construisant from scratch un framework qui te corresponde.... (ce que tout le monde fait au passage)

Tout d'abord merci beaucoup de prendre le temps de m'expliquer tout ça ;) !

Ensuite, pour commencer, merci pour le lien à propos des templates. Je l'ai juste parcouru, mais d'après toi je devrais développer mon propre moteur de templates ? C'est peut-être pas très sérieux, mais c'est une partie qui m'intéresse moins de développer :oops:...

Sinon, pour la généralisation des événements, je comprends bien. Ca s'applique parfaitement à la frontpage, comme tu l'as dit, mais comment gérer par exemple l'affichage d'un module spécifique ? Imaginons le calendrier ? On aimerait comme tu l'as dit afficher les 7 prochains jours sur la page d'accueil (donc sur l'événement "frontpage", le module Calendar va afficher son petit template à un certain endroit (prédéfini dans le template princpal ? ou plutôt placé dynamiquement grâce à des CSS ?).

Par contre, il va aussi falloir un événement qui n'affiche que le calendar. Cet événément sera donc par définition spécifique au module calendar non ? Mais, d'un autre côté, il devra aussi être global, dans le ses où des modules pour ce calendrier pourront être développés (affichage de la liste des gens ayant leur anniversaire ce jour, par exemple...)...

Peut-être pourrait-on définir un préfix pour les événements : "global_frontpage" pour la page d'accueil "globale", donc principale, "calendar_frontpage" pour la page principale du calendrier, etc...

Et de même pour l'interface d'administration : "admin_frontpage", "admin_calendar_frontpage", etc... De cette manière, il est facile pour un module de se "greffer" sur un autre s'il connait un peu son fonctionnement ? Je pense que la grosse difficulté est de bien définir ces événements... Il va falloir que j'y réfléchisse :roll:...

Dernière chose : qu'est-ce que ce principe d'ouverture/fermeture ? Je comprends l'ouverture aux extensions (un module peut toujours s'enregistrer pour n'importe quel événement), mais pas la fermeture aux modifications... :aie:

Merci encore !

Je te laisse voir pour les détails techniques qui sont propres à chaque conception/implémentation... ;)

Concernant le principe d'ouverture/fermeture :
Voici un code ouvert aux modifications (pas bien) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

class Wookai { function display_front_page() { $this->header();   //Affichage du forum $this->modules['forum']->displayFrontPage();   //Affichage de l'agenda $this->modules['calendar']->displayFrontPage();   $this->footer(); } }

---

Le jour ou tu as un troisieme module, News, qui arrive, comment fais-tu pour afficher les dernières news sur la front page : tu modifies le code existant pour rajouter la ligne :

Code:

---

$this->modules['news']->displayFrontPage();

---

Maintenant le meme exemple mais respectant OCP (Open/Close Principle) :

Code:

---

1 2 3 4 5 6 7 8 9 10

class Wookai { function display_front_page() { $this->header();   //Affichage des modules sur la front page $this->fireEvent('front_page');   $this->footer(); } }

---

Que dois-tu modifier pour ajouter les news : rien ! Il suffit juste d'écouter l'évenement qui va bien et c'est fini !

Là c'est flagrant comme exemple, mais ce principe est à respecter au maximum dans le reste de l'application... Car en terme de maintenance, la modification d'une ligne pour ajouter des fonctionnalités apporte souvent des bugs dans l'existant. Le but est donc de ne rien modifier : ouvert aux extensions (l'application peut évoluer) mais fermé aux modifications (mais on ne modifie pas (ou peu) le code existant)
Un peu de lecture : http://www.design-up.com/articles/de...pesoo/ocp.html

Génial, merci beaucoup pour ces explications ! C'est marrant que tu aies choisi mon pseudo comme nom de la classe, la version actuelle de mon admin ressemble pas mal au code "pas bien" :aie: !

Je lirai attentivement ce lien ce soir, encore merci !

Sinon, je profite du fait que tu sois très disponible, compétent et sympa pour te demander si tu peux développer un autre aspect, que je vois actuellement dans le cadre de mon stage (.NET :roll:...) : les tests.

Comment appliquer ça au développement d'applications web en PHP ? J'avoue avoir du mal à voir quoi tester (insertions dans la db ? affichages ?)... Penses-tu que ce soit adapté à ce genre de développements ?

J'ai entendu parler de simpletest (http://www.lastcraft.com/simple_test.php), qu'en penses-tu ?

Merci !

Waou tu sais flatter mon égo toi... :lol:
Non pas ma soi disant disponibilité ou ma prétendue compétence, mais quand tu parles de tests de surcroit avec SimpleTest, tu me brosses dans le sens du poil ;)

Perso je ne sais pas comment j'ai pu développer avant d'avoir découvrir SimpleTest... En fait cette librairie permet de faire des tests unitaires. Le but est de prendre une classe de lui envoyer des donner en entrée et de tester le résultat. Le jour ou tu modifie la classe pour lui rajouter une fonctionnalité tu rejoues le jeu de test afin de voir si tu n'as rien casser. Tu assure ainsi la non-regression de ton application. Si tu pars de zero, alors c'est le bonheur total, et en plus tu peux opter pour la méthode TDD (Test Driven Development ou Dévelopement piloté par les tests) :
Le schéma classique est : (les smileys sont importants)
je code
je teste => KO :cry:
je corrige
je teste => Ok :) , on passe à la suite

Avec TDD :
je teste => KO :)
je code
je teste => OK :) , on passe à la suite

Ca apporte une nouvelle vision au développement et tu as vraiment l'impression d'avoir un code béton. Sans TDD les tests sont chiants, avec, ils font partis de l'implémentation, de la conception, de la doc, ....
Un bug apparait ? =>
tu rédige un test qui reproduit le bug,
tu testes => KO mais c'est normal tu n'as rien corrigé
tu corrige le bug
tu testes => OK et roule ma poule ton bug ne ressortiras jamais car il est testé. Ainsi si dans six mois tu trouves un bout de code qui te semble inutile (alors qu'en fait il corrige un vieu bug) alors ton test sera la pour te mettre en garde.

Le top du top : les mocks.
Les mocks te permettent de tester un objet qui interragit avec d'autres objets sans que ces objets soient implémentés.
Ainsi tu peut développer entièrement une classe et qu'elle soit pleinement fonctionnelle et testé sans que les classes dont elles dépendent ne soient complètes... lovely.

Bref, je te conseille vraiment d'utiliser SimpleTest (ou son accolyte PHPUnit)

Héhéhé, content d'avoir pu te faire plaisir :mrgreen: ! Merci pour cette explication, c'est clair que ça a l'air alléchant ;) ! La boîte dans laquel je fais actuellement mon stage est adepte du TDD, et j'ai commencé à l'utiliser un peu...

Vu que j'ai la possiblité de commencer tout de zéro (à part les templates), je vais pouvoir mettre ce principe en application ! Test PUIS code !

Mais j'ai toujours de la peine à voir comment l'appliquer au développement web. Autant pour ce que je fais dans mon stage (bosser avec des streams, les séparer, les parser, extraire du contenu, etc...), je vois comment le tester (créer un stream dont le contenu est connu, lancer la procédure de parse et tester que le résultat obtenu est bien celui escompté), mais par contre pas trop pour ce genre d'application...

A la limite la classe qui gérera les accès à la DB, je vois comment la tester (requêtes sur une base de test), mais le reste...

Tout est testable :)
Par exemple tu peux tester que si tu ajoutes un listener pour un evenement donné et que tu lance l'évenement, alors le listener sera reveillé...