|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||||||
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Bonjour à tous,
J'ai commencé à développer un espace membre générique pour une utilisation future en essayant d'appliquer au mieux les principes du patron MVC. Tout fonctionne bien, j'ai développé les fonctionnalités suivantes :
J'utilise MySQL pour stocker les informations des membres. Je me suis attaqué à l'affichage de la liste des profils des membres et cela fonctionne bien mais je bute sur un problème : Je trouve que le code de ma Vue (qui affiche la liste des membres) contient "trop de code php", alors qu'elle devrait contenir, en principe, que de l'HTML... Voici mes sources : 1) la fonction du modèle "membres.php" : Code :
Code :
Code :
Ma question est : Est-il possible de recoder le contrôleur et la vue de manière à respecter la contrainte précédente que je me suis imposée? Merci infiniment pour toute suggestion qui pourrait m'aider à résoudre ce problème ! |
||||||
|
|
00
|
|
|
#2 | ||||
|
Membre confirmé
![]() ![]() Clément Développeur informatique Inscription : décembre 2006 Messages : 213 ![]() |
Ton code respecte déjà plus bien le MVC (contrairement à ce que l'on peut voir un peu partout) !
Pour l'améliorer, je vois pas grand chose : le code de ta vue, ne fait rien d'autre qu'initialiser une chaine de caractères, pour ensuite faire un echo dessus. Une solution un peu plus propre (et aussi plus efficace car pas de concaténation de chaine), est d'écrire le HTML directement comme template, et d'inclure les <?php ?> là où il faut. Ton code sera pas beaucoup plus court, mais tu gagnes en lisibilité avec un bon environnement de dev qui te fera la coloration syntaxique. Ca te permet aussi de bien indenter ton code, lorsque celui-ci sera plus complexe (plein de balises imbriquées). Exemple : Code :
Code :
EDIT : il te manque une balise td ouvrante dans ta table. |
||||
|
|
10
|
|
|
#3 |
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Merci Climoo pour ta réponse rapide.
Hélas, je n'ai pas encore étudié la possibilité d'utiliser un moteur de templates. Pour le moment, je développe pour m'entrainer à comprendre le patron MVC dans le but futur de pouvoir bien utiliser un framework comme Zend. En ce qui concerne mon code, merci, j'ai corrigé les oublis, et je ne vois pas non plus comment faire pour bien séparer la vue. En effet, la liste des membres est sujette à évolution : leur nombre n'est pas constant et fixé, ce serait trop simple ! Aussi je ne vois pas d'autre moyen, pour l'instant, que de construire un tableau HTML par concaténation d'une chaine .... A moins que ! Je pense maintenant à construire une classe de génération d'une table HTML avec comme attributs le nombre de lignes et colonnes. Genre : Code :
$tableau_membres = new Table($nb_membres, $nb_champs); Qu'en penses tu ? Faisable ? |
|
|
00
|
|
|
#4 | ||
|
Expert Confirmé
![]() Inscription : janvier 2010 Messages : 2 727 ![]() |
Salut
Je te donne un avis personnel (donc à voir). Qu'il y ait du code Php dans la vue n'est la plus grosse contrainte, à partir du moment où on ne mélange pas avec le modèle ou le controller ou autre. Ce qui m'interpelle le plus dans la manière où tu procède, c'est dans la récupération de la vue qui à mon sens manque ou manquera tôt ou tard de souplesse. Je te donne une technique qui est assez utilisée dans les FrameWork. L'idée est simple, c'est de pouvoir récupérer le contenu des vues à n'importe quel moment au niveau du controller. Un code/exemple vos mieux qu'un grand discourt. Juste le principe de base (donc code très basique, avec une fonction) : Code :
En somme, on est totalement indépendant du déroulement du Html, par conséquent on fait les chose selon le déroulement du Php, et ça change tout. Ensuite, le controller à la fin génère l'ensemble des vues une fois avoir recoller les morceaux dans le bon ordre (un système de template pourrait faire l'affaire par exemple). Tu remarqueras que la fonction attend un tableau, ce tableau peu contenir tout ce qu'on veut (comme d'autres tableau et même des Objets. Le tableau est extrait, et chaque élément sera une variable, elle pourra alors être exploité dans la vue. Comme je l'ai dit, c'est un code basique, plus pour voir si cela t’intéresse. Normalement il faudrait créer au minimum une classe View qui se chargerait de retourner la vue. Pour ma part, il est quasi impossible de créer des vues 100% statique (100% en Html), on a toujours besoin de données dynamiques. On peu exploiter des truc comme Smarty ou Twig, mais ceci me semble plutôt utile lorsque des non développeurs doivent intervenir dans ces fichiers. Ceci dit, ces outils là demandent d'apprendre un nouveau langage pour ainsi dire. Faut voir.
__________________
Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20 Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra] |
||
|
|
10
|
|
|
#5 |
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Merci à toi aussi RunCodePhp pour ton commentaire très constructif !
Effectivement, je commence aussi à penser que la vue ne peut être à 100% statique pour une application web évoluée. Très intéressante ta technique de récupération de la vue au niveau du contrôleur. Et c'est déjà un pas de plus dans le sens du développement d'un framework. Je n'ai pas cette prétention, mais si je pouvais me construire un ensemble de classes perso utiles et réutilisables, ce ne serait que bon pour mes projets ! Aussi pourrais tu, stp, me donner d'autres conseils voire des articles pour construire une telle classe View ?
|
|
|
00
|
|
|
#6 | ||
|
Expert Confirmé
![]() Inscription : janvier 2010 Messages : 2 727 ![]() |
La classe View
Code :
Ce FrameWork est excellent quand on débute dans ce domaine, car il est assez facile à prendre en main, le code n'est pas énorme/volumineux, on peu le parcourir petit à petit et comprendre comment tout ça se déroule. Son gros point faible, c'est la doc quasi inexistante, et le peu qu'il y a est souvent obsolète, car non compatible entre les anciennes et nouvelles versions. Ca reste une solution, sans nulle doute qu'il y en a d'autres.
__________________
Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20 Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra] |
||
|
|
00
|
|
|
#7 |
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Je vais retenir l'idée et parcourir le code de Kahona plus tard, car j'ai peur que mes connaissances actuelles ne puissent pas encore m'aider à le comprendre.
Il me faut encore un peu plus de théorie sur le MVC et les constituants d'un framework avant d'en aborder un ! Je vais continuer à lire des articles et tutos sur le sujet. Quand le moment sera venu je mettrai mon nez dans le code ... |
|
|
00
|
|
|
#8 | ||||
|
Expert Confirmé
![]() Inscription : janvier 2010 Messages : 2 727 ![]() |
Retiens tout de même cette technique de chargement de vues indépendant, ça t'apportera un gros plus, ça ne fait aucun doute, même en le faisant avec une simple fonction comme dans l'exemple.
Un exemple pour utiliser cette fonction : Code :
Code :
Ceci permet de mettre directement du HTML ou des echo dans les vues, donc d'éviter comme tu le fais de tout stocker dans une variable. Mais surtout, ça évite tout conflit avec des noms de variables qui pourraient être communs à plusieurs vues. En somme, comme on passe par une fonction et qu'en plus tout est vidé après exécution, on ne rencontrera pas de problème de portée (ou visibilité) sur les variables. Ensuite, il me semble que le controller ne soit pas Objet, mais procédural. Si c'est le cas, il faudrait améliorer ce point là, faire une classe genre FrontController, une classe Parente à tous les controller. Puis créer une classe Controller par page. Aussi, faudrait voir comment toutes ces pages sont structurées/organisées. Il est bon de s'imposer une structure et aussi certaines règles de nommage des fichiers se qui permettra d'automatiser un peu plus les choses. Par exemple, stocker tous les controller dans un répertoire "controller", les modèles dans un répertoire "model", et les vues dans "view". Ensuite nommer chaque classes comme : Model_listeMembres (nom du fichier : Model_listeMembres.php) Controller_listeMembres (nom du fichier : Controller_listeMembres.php) View_listeMembres (nom du fichier : View_listeMembres.php) L'idée est de nommer les classes selon l'arborescence adoptée, se qui par exemple permettra de faire un auto-chargement de classes (un autoload). En somme, chaque underscore (_) correspond à un slash (/) du système de fichier. (Kohana, ZendFrameWork entre autre adoptent se principe là).
__________________
Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20 Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra] |
||||
|
|
10
|
|
|
#9 |
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Plus je relis tes messages, et plus je comprends leur contenu ! C'est formidable !
J'aime de plus en plus cette manière (le MVC) de structurer une application, qui est bien entendu néanmoins difficile à aborder. Pour résumer : 1) Je vais restructurer mon arborescence et renommer mes fichiers selon la convention de nomenclature que tu m'as conseillée. J'ai déjà fait une bonne partie du travail dès le départ, mais je n'ai pas utilisé les préfixes "Controler_", "View_" et "Model_". C'est la première chose à faire, je pense, et il faudra penser à recoder tous les appels aux fichiers utilisés dans le module. Juste ? Donc, ensuite : 2) Je vais coder une classe autoload générique pour mes appels aux trois différentes parties : les controlers, les view et les models. 3) Je vais lire les articles http://julien-pauli.developpez.com/t...vc-controleur/ et http://tahe.developpez.com/web/php/mvc/. Ils vont me permettre de mieux comprendre les classes de FrontControler et les Controler et de View. Je vais tenter finalement de recoder mon module d'espace membres avec les mêmes fonctionnalités mais en "objectifiant" les blocs redondants. Voilà, tu m'as donné les infos, je te remercie encore, car j'en ai saisi une bonne partie. Par contre je sais pas si j'ai bon dans ma manière d'ordonner un peu mes futures taches. Ai-je bon ? |
|
|
00
|
|
|
#10 | ||
|
Nouveau Membre du Club
![]() Cédric BohnertEn auto-formation Inscription : juillet 2004 Messages : 71 ![]() |
Re,
J'ai trouvé sur ce blog une classe Autoloader universelle dont voici la source : Code :
Mon arborescence est la suivante :
Maintenant je vais bosser sur mon module membres proprement dit, à savoir, les controlers, viewers, et models. |
||
|
|
00
|
|
|
#11 |
|
Expert Confirmé
![]() Inscription : janvier 2010 Messages : 2 727 ![]() |
Là, il y a des choses qui me dépassent
Pourquoi fais tu des codes selon l'environnement de Php (php5.2/php5.3) ? Est-ce par ce qu'il y aura plusieurs personnes/codeurs qui utilisera ton code dans des environnement Php ? (comme tout projet Open Source finalement). C'est quoi au juste "un espace membre générique" ? Je ne sais ce que les autres pense sur le sujet, mais offrir une compatibilité Php5.2 et Php5.3 comme les namespace ça me semble rudement compliqué voir impossible, c'est pas loin d'être comme Php4 et Php5. Dans tous les projets Open Source que je vois, ils optent pour 2 versions différentes, du moins ça me semble le cas pour php5.2 et php5.3 à cause des grosses différences qu'il y a entre ces 2 versions. Est-ce que selon ton besoin la création de nouvelles pages (nouveaux controller entre autre) doit être modulaire ? De mon coté je perçois plutôt qu'un module c'est une fonctionnalité en plus du "moteur" (ou core) de base. Par exemple : une connexion à une Bdd, envoyer un mail, créer un PDF, parser un XML, etc ... Juste pour exemple, les structures s'approchent de ceci : .root/www/ (fichiers publique [images, css, js, etc ...]) .root/system/ (le core du projet [commun à 1 voire plusieurs applications/site Web]) .root/application1/model/ .root/application1/view/ .root/application1/controller/ .root/modules/mailing/ (bibliotèque pour envoyer des mails) .root/modules/pdf/ (bibliotèque pour créer des PDF) ... etc ... autres modules ... Ici, on peu donc utiliser un "core" commun à plusieurs applications (sites Web) Les modules sont aussi indépendant (comme le core), toutes les applications peuvent les exploiter. (Si on crée un autre site sur le même serveur, on créera alors un autre virtual host (genre www2), et un autre répertoire pour l'application (genre application2). Ceci dit, rien empêche de créer dans chaque application un répertoire "genre lib" pour créer leur propre librairies spécifiques. Ca peut être de nouvelles classes, classes étendues des modules communs, classes étendue du core, etc ... C'est juste un exemple de structure évidemment, tout dépend des besoins.
__________________
Win XP | WampServer 2.2d | Apache 2.2.21 | Php 5.3.10 | MySQL 5.5.20 Si debugger, c'est supprimer des bugs, alors programmer ne peut être que les ajouter [Edsger Dijkstra] |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com