Discussion :

[UNi[FR]]

...Avant tout, il faut coder de manière à ce comprendre en premier mais tout en étant pas dans l'optique de compresser pensant que ça va augmenter la vitesse....

Aprés on appel ça la maitrise, à force de faire du PHP on commence à savoir quelle fonction est mieux qu'une autre en terme de performances.

Exemple : si ton tableau contient beaucoup d'éléments il est préférable d'utiliser une boucle for plutôt que foreach.

[Fladnag]

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

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.

[Djakisback]

Ca me permet également au moment d'assigner une valeur à une variable de me rendre compte immédiatement si je suis en train de faire n'importe quoi (par exemple $lbVar = 'toto' alors que c'est un booléen), je sais immédiatement qu'un truc cloche.

Evidemment on maitrise notre code, et en PHP ça n'aura aucune incidence et moins d'intérêt, mais il s'agit là de se construire une logique appliquée à n'importe quel langage et dont l'idée est de savoir que le code peut-être lu par d'autres personnes (je trouve ça plus explicite). Comme je le disais c'est une logique strictement personnelle, après on y trouve un intérêt ou non.

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).

[Delprog]

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 :

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}

Ou :

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

Je me demande....

[berceker united]

Je reviens aussi sur les différentes couches de l'application, fonctionnelle et vue pour simplifier (il y en a d'autres).

Tout le monde parlent de templates et se met en tête de vouloir absolument séparer intégralement le php du html.
Je suis d'accord il ne faudrait jamais voir du HTML dans du PHP, mais l'inverse ? Je me pose la question quand même...

J'ai envie de dire que tout dépend du but final de l'application. S'il s'agit de créer (comme les forums phpbb par ex.), une usine à gaz qui pourra être personnalisée par n'importe qui dans la couche vue sans prendre le risque de modifier la partie fonctionnelle d'accord. Mais je le redis, il s'agit en général d'usines à gaz, et tout le monde sait que les hébergeurs (en mutualisé surtout) n'aiment pas beaucoup ce genre d'application.

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

Maintenant admettons qu'on ait un projet abordé avec une bonne conception Objet, des classes propres et bien construites, n'intégrant aucun html biensur.

Si ce projet était de proposer différents "templates" pour des sites clients permettant de lister par exemple des produits en fonction de critères de recherche (très répandu hein).

Par exemple mes produits seraient des "trucs" ok. Sur ma page d'accueil, j'ai une liste de "trucs" et le détail d'un seul "truc".

Qu'y-a-t'il de mauvais à avoir par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
// Avant ça création de la connexion à la BDD avec une classe générique
// et on aurait au final un objet $db
 
$listeTrucs = new ListTrucs($db, $id_client);
$listeTrucs->getListBySearch($criteres, $_POST);
 
$monTruc = new Truc($db);
$monTruc->getTrucById($listeTrucs->items[0]['id_truc'] );

J'invente hein, evidemment ce serait plus réfléchis que ça.

Mais qu'est-ce qui empêche vraiment pour la vue de faire directement dans le HTML :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
$count = count($listeTrucs->items);
for ($i = 0; $i < $count; $i++) { ?>
 
<div id="items-list">
  <div class="item"><?=$listeTrucs->trucBidule?></div>
</div>
 
<?php
}
?>

Ok c'est moins lisible, mais n'est-ce pas bien plus performant ?

Je vous pose la question, la séparation totale des couches a-t-elle un autre intérêt que la lisibilité ? Perso, j'essaie de séparer au maximum aussi, mais je me pose quand même la question sur l'intérêt réel.


Benjamin.

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.

[mon_nom_est_personne]

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).

[Nicam]

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 ...

[Nicam]

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).

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.

[fadex]

si qqun a de bons tutos, qu'il fasse ... péter ^^

moi je vous dit si vous avez des tutos pour avoir une bonne maitrise de la MVC et les design pattern ... 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 seul depuis 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

[Nicam]

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é ....

[zyongh]

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.

[Nicam]

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.

C'est aussi très vrai.

[nabbo]

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 ;-)

[Nicam]

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

[Ekimasu]

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.

[nabbo]

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)

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

/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
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

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));
	}
}
?>

/modele/user.class.php //obtient les données sur les utilisateurs
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

[s4mk1ng]

il faut mettre des explications et bien espacer son code pour qu'il soit lisible

[Molos]

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

[nabbo]

il faut mettre des explications et bien espacer son code pour qu'il soit lisible

il est aéré mon code... non ?

les explications, j'ai l'impression d'en avoir mis. qu'est ce que tu penses qu'il faut que je rajoute ?

[zyongh]

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.