Petite digression... les templates permettent de faire du code générique, et rendre son code générique permet aussi d'appliquer des concepts génériques dessus comme la notion de cache.
J'avais lu une étude sur smarty pour ne pas le nommer... qui utilise des template et un cache... au final, le cache permet d'avoir un gain sur l'execution et la rapidité par rapport a une version sans cache ni template (bref, sur du code php/html classique) ! Meme si la 1ere génération de page est forcement plus longue, du code PROPRE et PERFORMANT est toujours réalisable avec des templates quand on sait ce que l'on fait.
Au contraire, il y a que dans un langage non typé que ça a un intérêt. Essaie de mettre un bool dans un int en C++ ^_^, tu le sauras tout de suite que ça cloche. En PHP si tu te retrouves avec un bool en t'attendant à avoir un int tu peux arriver à quelque chose d'un peu chiant à debuguer
Au sujet des templates ou encore du MVC, il me semblait que l'un des avantages était la maintenance. Effectivement, si c'est toi qu'a pondu le code la maintenance est plus simple mais si le découpage a été fait par quelqu'un d'autre, ça peut être vraiment galère de remonter à l'endroit qui t'intéresse pour faire juste une petite modif, avec toutes les indirections des fois tu t'en sors pas (à moins d'utiliser un debugger).
Non mais ce que je veux dire, c'est que si on prend par exemple Smarty. Le système de boucle n'est franchement pas plus simple à lire qu'une boucle "for" classique beaucoup plus répandue.
Et si un monteur intervient sur le HTML, je ne suis pas sur que ça change grand chose pour lui. Il ne faut pas être une tête pour piger comment fonctionne une boucle.
Après je sais bien que ça peut avoir d'autres avantages, comme "le codeur code" et le "monteur monte". Mais quand même, si encore une fois je prend l'exemple de Smarty qui est très répandu, nous autres codeurs on comprendra vite le système. Mais un néophyte lui aura déjà beaucoup plus de mal....
Alors quel est le plus facile à lire :
Ou :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3 {section name=id_tableau_smarty loop=$tableau_smarty} <li>{$tableau_smarty[id_tableau_smarty]}</li> {/section}
Je me demande....
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8 <?php for ($i = 0; $i < count($monTableau); $i++) { ?> <li><?=$monTableau[$i]?></li> <?php } ?>
Si éléments susceptible d'afficher des données sur l'écran est concentré au même endroit cela ne pose pas de problème pour ma part, il ne faut pas que ça puisse être éparpillé n'importe ou dans l'organisation.
Dans mon cas, j'ai un groupe de classe qui ne fait que du traitement d'affichage. Après, c'est une question de choix.
Je te rejoins sur le faite que le système de template actuelle n'est pas de ce qui est le plus apprécié chez les hébergeurs parce qu'il y a beaucoup d'usine à gaz dans ce domaine.
pour repondre a delprog, je comprend tout a fait ton point et tu as raison de stipuler que l'utilisation de moteur de template (smarty) depend du projet mais aussi de l'environnement de travail. Quand tu bosse seul tu peux te permettre d'etre un peu cochon sur les vues, mais quand tu travail en agence avec des designers, crois mois un if smarty leur fait moins peur qu'un if php.
Mais tu as a pointer un tres bon point concernant "une bonne prog" : choisir ses outils en fonction de son projet. Ca sert a rien de se prendre la tete pour un form de contact (que j'ai deja vu).
Pour bien coder en PHP, je dirais que les règles s'appliquent aussi à d'autres langages.
1 - Avoir une vision globale du projet (ou du bout de projet que l'on nous a confier). Ca permet de bien mesurer les contraintes des solutions que l'on va utiliser.
2 - Avoir des notions de modélisation. Savoir prendre du recul, et ne pas hésiter à utiliser l'abstraction.
3 - Pour un projet Web, bien maitriser les tenants et aboutissants du MVC(2).
A mon avis, il ne suffit pas d'utiliser un framework MVC si on ne comprend pas son intérêt. Un moteur de Templates reste orienté vue. Qu'en est il du modèle ?
C'est à mon avis le plus difficile. Je connais peu de personnes qui maitrisent réellement MVC, et même dans le monde JEE, je suis témoin de sacrées conneries ... Le fait d'utiliser Strust peux donner bonne conscience, mais ce n'est pas suffisant. En php, c'est pareil ...
A la limite, pour débuter, je conseillerai de ne pas utiliser de framework, mais plutôt d'implémenter soi même, simplement, l'architecture MVC. C'est très instructif.
4 - Rester cohérent dans la façon de coder. Peux importe les règles adoptées, si elles le sont au début, elles doivent le rester jusqu'à la fin ...
5 - Faire du code sécurisé : Ne faire confiance à personne, vérifier les entrées (au niveau de la vue, mais aussi au niveau de la base, avec les requetes préparées), etc ...
6 - Pensez si possible à la réutilisation. C'est un exercice difficile, et couteux.
Mais surement avantageux à long terme.
7 - Passer à l'objet pour la couche métier (dans le modèle. Et se demander pourquoi les design pattern existent (oui, il y a bien une raison
)
8 - Privilégier les architectures simples. C'est souvent oublié, et par élitisme, on tombe souvent dans l'usine à gaz.
9 - Tester la moindre classe. Ne pas hésiter à monter en compétence en tests unitaires. (D'ailleurs, je manque sérieusement d'expérience en TU, si qqun a de bons tutos, qu'il fasse ... péter ^^)
10 - Documenter son œuvre : Eviter les tonnes de documents word incompréhensibles. Quelques lignes bien placés, de petits shemas au besoin, ca marche aussi bien que de longs textes indigestes...
Et j'en oublie surement ...
Je ne suis pas d'accord.
Déjà, ton form de contact fait parti d'une application dans son ensemble.
Si le reste de l'application utilise un moteur de template, pourquoi pas lui ,
Au passage, le moteur de template va utiliser des templates (logique) qui vont apporter une certaine homogénéité dans l'aspect (le design de la page).
Utiliser tes templates te garantie au maximum une coherence dans l'ensemble.
Je voudrais revenir sur un point qui me semble important dans le débat du code PHP avec le HTML.
Voici ce que je retire ma popre expérience :
Je considère que la vue ne doit faire AUCUN traitement en php, si ce n'est que de cracher du HTML.
Le meilleur exemple à mon gout est le moteur de template de PHPbb2 (je n'ai pas vu le moteur de la version 3).
Une classe qui génère un tableau HTML a sa place dans la vue.
Une classe qui calcule le prix total d'un caddie virtuel n'a rien à faire dans la vue.
Une classe qui accède à la base de données n'a rien à y faire non plus.
Une classe qui vérifie les droits non plus ...
Si je pouvais parler à ma couche présentation, je lui dirais :
"Hey mec, toi qui est en charge de d'afficher une page web, je veux que tu la construise avec les données que voici, pour cela, tu devras afficher un tableau, et tout pmleins d'autres choses".
Pour rappel :
Template (Contient du HTML et des balises specifiques simples) + Moteur de template (Contient du PHP qui génère du HTML, ou autre ...) appartiennent à la vue. Il ne doivent pas contenir du code métier, et n'ont pour but que de générer des pages en fonction des données en amont, récupéré du Modèle, mais transmises par le contrôleur.
Alors oui, nous pouvons mélanger le PHP dans le HTML, même si c'est concentré à un même endroit. Mais c'est franchement crado.
Le moteur de template (mais c'est aussi le cas d'autres solutions) a le mérite de forcer le développeur à positionner son code au même endroit.
A long terme, ca évite de se retrouver avec du code métier dans la vue... Chose qui arrive très vite lorsque l'application est maintenue par pleins de personnes différentes au cours du temps.
moi je vous dit si vous avez des tutos pour avoir une bonne maitrise de la MVC et les design pattern ... péter ^^si qqun a de bons tutos, qu'il fasse ... péter ^^
il y a plain de sites qui parle à gauche et à droite mais pas un vrais tutos qui vous explique les chose.
Je bosse seuldepuis 17 mois sur un projet web en PHP et mnt je me retrouve avec des conneries par tout (une usine a gaz) , et je vois bien l’utilité de la MVC et les design pattern...
Pour utiliser la MVC, Système de Template, TU, design pattern il vous faut une équipe sinon tu te retrouve devant un projet comme le mien![]()
C'est justement pour cela que je dis que la compréhension du MVC est primordiale. Et de ce que j'ai vu sur les dernières pages me fait comprendre que peu ici le maitrisent.
Faire du MVC, c'est contraignant, mais c'est très structurant.
Si le développeur à compris l'utilité de ce design pattern, son code sera logique, et plus facile à maintenir.
Je suis contre ta dernière phrase :
C'est justement au moment ou tu peux t'en sortir seul que tu vois si le MVC a été bien implémenté ....
Programmer en MVC n'est utile que pour les gros projets. Pour des petits sites web par exemple, c'est mettre beaucoup de lignes de codes pour pas grand chose.
Je suis un adepte de la programmation MVC sur les gros projets et non... il n'y a pas besoin d'être toute une équipe pour maintenir un code programmé en POO (dont l'architecture MVC fait partie).
J'ai déjà programmé un projet de plus de 30000 lignes de codes en 6 mois dont environ 20000 pour le back-office grâce à un framework MVC et le maintenir ne me prends que quelques heures par mois.
Bonjour tout le monde
je parcours ce sujet qui est assez intéressant.
Mais je ne vois pas d'exemple concret de mise en oeuvre d'une architecture MVC "simple", sans utiliser de framework usine à gaz.
pour la vue, le comparatif des systèmes de templates (disponible ici) semble indiquer que la classe de template de phpbb2 est très proche d'une vue "pure" puisque aucune instruction "avancée" n'est présente dans le code.
pour le modèle, les instructions mysqli* semble rassembler pas mal de monde, même si elles sont cantonnées à Mysql, donc pas franchement génériques.
malgré tout, alors que je pense avoir compris le principe de séparation, je n'arrive pas à l'appliquer en pratique. je ne sais pas comment donner à mon modele un objet de base de données, etc.
est ce que quelqu'un pourrait montrer rapidement le code avec par exemple un fichier index.php (controleur) qui va piocher des données quelconques dans une table (en utilisant une classe modele) pour les afficher dans une table html toute simple (en utilisant une classe template phpbb2, par exemple ?)
et comment gérer l'inclusion de pages multiples (les "include" de php) ?
si quelqu'un a le temps et la patience de poster ça, ca serait super sympa, et je pense que ca ferait avancer beaucoup le topic ;-)
Tu peux programmer en couche, comme l'impose MVC2 sans passer par un framework.
A partir du moment ou tu positionnes ton code aux bon endroits, et que le code réalise ce qui est requit à cet endroit, tu codes déjà en MVC.
Je n'ai pas accès à la doc de Phplib (pour le template de PHPbb2) sur le moment, mais je peux deja te donner une piste.
Admettons que tu dois afficher un tableau d'utilisateurs.
voici les fichiers que j'utiliserais
index.tpl (vue)
index.php (vue)
controler.php (controleur)
dataService.php (modele)
sgbd.php (modele)
index.tpl est le template de la page de sortie.
Il represente la vue finale, suite à la requete (tu y mes du HTML et des balises de templates)
Lorsque tu requetes index.php, tu appelle accede à la vue.
Cette vue transmes les informations au controleur.
Là, il n'y a pas de données, mais si il y a un formulaire (par exemple) dans index.php, il faut transferer les données.
controler.php intercepte la requete.
C'est à lui de comprendre ce que veut l'utilisateur, et de lancer les traitements voulus. Une fois les traitements effectués, et les données rapatriées par le modele, il doit rediriger le client vers index.php (qui lui generera la vue vie index.tpl).
Le controleur lance alors une méthode du modèle (qui se trouve dans dataService.php) du genre getUsersList();
Mais comme notre list d'user est en base de données, il faudra que getUserList() appelle elle meme une methode getData() de dataService.php
getData() appellera alors une methode bas niveau (niveau abstraction) de sgbd.php (la requete SQL).
Aussi, si demain, on decide de mettre la liste des utilisateurs dans un annuaire LDAP, par exemple, il faudra creer le fichier ldap.php, et coder la requete dedans.
Dans getData(), on dira simplement de ne plus utiliser sgbd.php, mais ldap.php
Le reste ne doit pas changer.
En retour, le controleur doit recevoir un flux de données venant du modèle.
Ce flux ne doit pas etre formaté, ca sera le role de la vue de faire ca.
On peut tres bien imaginer que la methode getUsersList() retourne un Array, et que chaque ligne de l'array comporte un objet user.
Ta question était, si j'ai bien compris, comment passer du relationnel (la base), à de l'objet.
Tu dois faire un mapping.
Si ta requête sql retourne 4 champs, et que ton objet comporte 4 propriétés, tu dois avoir un bout de code en PHP qui fait la manipulation.
Il y a des tas de mécanisme plus ou moins élaboré qui font ca.
mais c'est archi faisable à la main. POur un petit projet, il ne faut pas s'en privé.
Au final, la couche vue n'a que deux elements avant d'afficher la page :
- la template à utiliser
- Les données à y inclure.
Ais je été clair ?
PS : il n'y a pas de recette miracle, il y a milles et une facon de coder, mais le plus important est bien de comprendre ou se situe les traitements dans les couches. Et pour ca, c'est vrai que faire un petit tour dans le monde de java est très appréciable, et formateur, meme si on n'aime pas Java![]()
PHP est un langage simple donc il est important que le code écrit soit simple aussi.
Bcp de gens codent comme si la ligne de code était payante.
Donc j'évite les profusions de function appelant de function qui appelle des fonctions..Etc
l'important dans une apli PHP, est qu'elle soit immédiatement accessible lors d'un débug ou lors d'une TMA.
L'optimisation du code n'est pas importante car l'évolution matériele (perf) permet de s'en passer : ça coute moins cher d'acheter un serveur avec un meilleur CPU/pluis de RAM que de payer quelqu'un 1 semaine pour venir reprendre le code de quelqu'un.
j'essaie d'illustrer un peu.
Je ne me rappelle plus de la syntaxe de la phplib, donc on va improviser (flemme de regarder)
je prend un site qui affiche un liste d'utilisateurs dans un tableau, et quand on clique sur un utilisateur dans le tableau, on obtient sa description.
Je poste juste l'affichage, et on verra après où on rajoute le code pour, par exemple, ajouter un utilisateur.
je prends la structure suivante. les dossiers illustrent si je classe tel ou tel fichier / classe dans le M, le V ou le C :
Contrôleur
/index.php le "front controler", si j'ai bien compris
/controleur/top.php qui appelle la vue qui affiche le bandeau en haut de la page. Pas d'infos du modèle , juste un appel à la vue et à un morceau de template
/controleur/users.php qui appelle le modèle pour obtenir la liste des users, puis donne cette liste à la vue pour qu'elle l'affiche
/controleur/id_card.php qui fait la même chose, mais pour un utilisateur seulement
Modèle
/modele/bdd.class.php la classe générique bas niveau qui donne les functions query, etc
/modele/user.class.php va piocher dans la base les infos sur les users, en utilisant les fonctions de bdd.class.php
Vue
/vue/template.php la classe qui contient les fonctions qui parsent les templates
/vue/templates/*.tpl répertoire qui contient les templates, donc que du HTML, et des balises de template
Maintenant les fichiers :
index.php
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27 <?php require('./vue/template.php') //la classe de template, par exemple phplib require('./modele/bdd.class.php') //la classe bas niveau pour les requêtes en BD include('./controleur/top.php') //appelle la vue qui affiche un bandeau //le front-controler décide quel morceau de contrôleur doit être appelé, selon l'argument $_GET['page'] if(isset($_GET['page'])) { switch ($_GET['page']) { case 'users' : include('./controleur/users.php'); break; case 'idcard' : include('./controleur/idcard.php'); break; default : include('./controleur/default.php') } } ?>
/controleur/top.php (la syntaxe de la vue est probablement fausse, mais peu importe)
/controleur/users.php (obtient les données sur tous les users, et appelle la vue qui affiche le tableau)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11 <?php $template->choose_template('./vue/top.tpl','template_top'); //je dis quel fichier parser $template->assign_variable('template_top','logo_top','chemin_image_quelconque'); //je donne l'image de l'image à afficher (exemple quelconque, peu importe. ça ne vient pas forcément du modèle) $template->assign_variable('template_top','slogan_top','un slogan_quelconque'); //pareil $template->parse_template('template_top'); //je parse le tout ?>
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17 <?php $template->choose_template('./vue/users.tpl','users_tableau'); $myuser=new user(); $users=$myuser->getAllUsers(); foreach ($users as $user) { $template->assign_variable('users_tableau','user_name',$user['name']); $template->assign_variable('users_tableau','user_id',$user['id']); } $template->parse_template('users_tableau'); ?>
/controleur/one_user.php (obtient les données sur UN user, et appelle la vue qui affiche sa "id_card")
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 <?php $template->choose_template('./vue/id_card.tpl','user_idcard'); $myuser=new user(); $user_name=$_GET['username']; $one_user=$myuser->getUser($user_name); $template->assign_variable('user_idcard','user_name',$oneuser['name']); $template->assign_variable('users_tableau','user_id',$oneuser['photo']); $template->parse_template('user_idcard'); ?>
/modele/bdd.class.php //les fonctions bas niveau. c'est juste pour l'exemple
/modele/user.class.php //obtient les données sur les utilisateurs
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 <?php class bdd { public __construct($host,$login,$pass,$bdd) { return mysqli_connect($host,$login,$pass,$bdd); } //ici, au passage, je sais pas comment gérer les requêtes paramétrées : le nombre d'arguments (assimilés à des ? dans une requête paramétrée...) est variable !? public query($sql) { return mysqli_fetch_assoc(mysql_query($sql)); } } ?>
pas vraiment une classe, juste un ensemble de fonctions...
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14 <?php class user { //ici : comment la class user connait-elle l'objet $db ? public function getAllUsers() { return $db->query("select * from users"); } public function getUser($name) { return $db->query("select * from users where name ='$name'"); } } ?>
Maintenant les questions :
Comment les fichiers du modèle obtiennent l'objet $db ?
De même, comment les fichiers de la vue obtiennent l'objet $template ?
Ensuite : comment où est ce que j'instancie ces fameux objets ?
dans index.php ?
dans chacun des contrôleurs ?
Voilà. D'autres questions viendront, j'espère faire avancer un peu le topic![]()
il faut mettre des explications et bien espacer son code pour qu'il soit lisible
Pour nabbo, je suis dans le même cas que toi, et donc pour que mes méthodes ai accès à mon objet $db, j'initialise l'objet dans mon fichier cfg.php, qui me permet de mettre les paramêtres pour la base de données, et d'ouvir une connexion.
Ensuite, dès qu'une méthode à besoin de mon objet $db, je met un global $db et le tour ai joué, après je sais pas si c'est une bonne solution, mais en tout cas ça marche![]()
Il est très bien aéré ton code et même très clair. Donc pas besoin de commentaire supplémentaire. Il faut aussi que ceux qui te lisent cherchent à comprendre et ne pas les nourrir mais leur apprendre à jardiner.
Personnellement, je ne mettrais pas de classes dans le répertoire modele/ mais dans le répertoire include/. Et tout ce qui est classes et controlers seraient placés dans ce répertoire include/ car mes controlers sont programmés sous forme de classes.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager