|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Membre habitué
![]() |
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
__________________
Wookai
|
|
|
00
|
|
|
#2 |
|
Membre habitué
![]() Giuseppe DamianiDéveloppeur Web Inscription : décembre 2003 Messages : 76 ![]() |
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/ |
|
|
00
|
|
|
#3 |
|
Membre habitué
![]() |
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 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 Merci en tous cas !
__________________
Wookai
|
|
|
00
|
|
|
#4 |
|
Membre éclairé
![]() Inscription : août 2006 Messages : 379 ![]() |
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 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. |
|
|
00
|
|
|
#5 | ||||
|
Membre habitué
![]() |
Citation:
Citation:
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:
Citation:
Merci pour ton intervention en tous cas !
__________________
Wookai
|
||||
|
|
00
|
|
|
#6 | ||
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
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 : Et pour chaque module : Code :
__________________
Get your motor runnin' Head out on the highway... |
||
|
|
00
|
|
|
#7 | ||
|
Membre habitué
![]() |
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
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 :
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 Merci ! La discussion reste ouverte, si vous avez d'autres conseils/réactions
__________________
Wookai
|
||
|
|
00
|
|
|
#8 | ||||||||
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
Citation:
Quand aux templates je te suggère de lire cet article : http://www.massassi.com/php/articles/template_engines/ Citation:
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:
Citation:
Citation:
Il faut raisonner à un plus haut niveau. Citation:
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)
__________________
Get your motor runnin' Head out on the highway... |
||||||||
|
|
00
|
|
|
#9 |
|
Membre habitué
![]() |
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 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 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... ![]() Merci encore !
__________________
Wookai
|
|
|
00
|
|
|
#10 | ||||
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
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 :
Code :
$this->modules['news']->displayFrontPage(); Code :
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
__________________
Get your motor runnin' Head out on the highway... |
||||
|
|
00
|
|
|
#11 |
|
Membre habitué
![]() |
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"
!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 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 !
__________________
Wookai
|
|
|
00
|
|
|
#12 |
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
Waou tu sais flatter mon égo toi...
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 je corrige je teste => Ok Avec TDD : je teste => KO je code je teste => OK 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)
__________________
Get your motor runnin' Head out on the highway... |
|
|
00
|
|
|
#13 |
|
Membre habitué
![]() |
Héhéhé, content d'avoir pu te faire plaisir
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...
__________________
Wookai
|
|
|
00
|
|
|
#14 |
|
Expert Confirmé Sénior
![]() Inscription : septembre 2004 Messages : 5 421 ![]() |
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é...
__________________
Get your motor runnin' Head out on the highway... |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com