Comme je débute dans la programmation sérieuse, j'ai plein de questions "philosophiques".

la dernière est la suivante.

description rapide:

j'ai une classe "connexion" qui instanciée renvoie un objet connexion.
j'ai une classe abstraite "base" dont le constructeur utilise l'objet connexion et qui génère des requêtes SQL basiques.
j'ai d'autres classes qui toutes héritent de "base", par exemple la classe "utilisateur" qui gère les méthodes des utilisateurs comme par exemple obtenir leurs rôles, nom, prénom etc...
j'ai une classe "formulaire" qui hérite aussi de "base" et génère par exemple des listes déroulantes et d'autres choses en faisant des print() pour générer le code HTML.

Question sur les bonnes pratiques:

Générer le code HTML d'une fiche utilisateur, relève t'il de l'objet "utilisateur" ou de l'objet "formulaire" au quels le contrôleur passe les arguments adéquats après les avoir obtenu de l'objet "utilisateur" ?

PS: j'espère ne pas me noyer dans un verre d'eau.

Ni l'un ni l'autre, c'est à ta vue de générer le html, pas à tes contrôleurs, non je suis pas HS y a écrit MVC

...c'est à ton modèle de générer le html...

C'est le MVC selon katagoto ? Alors une petite mise à jour s'impose

On va faire ça très schématique :
- Le modèle s'occupe de l'accès aux données et de retourner ces données brutes;
- Le contrôleur reçoit la requête HTTP et selon la page demandée fait appel au modèle approprié, récupère les données retournées par ce modèle et ensuite appelle la vue correspondante;
- La vue est le squelette de la page assorti de variables qui seront remplacées par les valeurs, et ceci est effectué par le contrôleur.
À noter qu'il ne devrait y avoir aucun lien direct entre la VUE et le MODÈLE.

Donc pour Alf, la génération du HTML relève de la VUE et cette vue sera appelée et pilotée par le CONTROLEUR. Dans ta description, on a seulement le MODÈLE : C'est ton CONTROLEUR qui va s'occuper de gérer la génération HTML en faisant appel à la VUE qui va bien.

D'autant qu'il y a plusieurs façons de voir le MVC.. le contrôleur passe les commandes de la vue au modèle, et au modèle de mettre la vue à jour. C'est une boucle.

Centraliser tout sur le contrôleur, ça porte un autre nom je crois..

ps: en plus, selon wikipedia, la vue peut générer une page tout seul en prenant les données du modèle.. http://en.wikipedia.org/wiki/Model-view-controller

...c'est à ton modèle de générer le html...

C'est le MVC selon katagoto ? Alors une petite mise à jour s'impose

Quand je parlait de Modèle, je pensait à template (en anglais) qui est souvent synonyme de vue, ok

Je sort --> []

ventilation mecanique controler non c'est pas sa VMC
MVC ah les lettre ne sont pas dans le meme ordre
ok j'allais vous faire un cours sur la VMC j'avais donc rien compris...

- La vue est le squelette de la page assorti de variables qui seront remplacées par les valeurs, et ceci est effectué par le contrôleur.
À noter qu'il ne devrait y avoir aucun lien direct entre la VUE et le MODÈLE.

Donc pour Alf, la génération du HTML relève de la VUE et cette vue sera appelée et pilotée par le CONTROLEUR. Dans ta description, on a seulement le MODÈLE : C'est ton CONTROLEUR qui va s'occuper de gérer la génération HTML en faisant appel à la VUE qui va bien.

ok je comprend mieux en quoi mon modèle diffère du MVC.
- mon squelette de page dépend de l'url
- il est complété à l'aide d'une classe "formulaire" qui fait appelle aux données en lecture pour construire certains éléments (listes déroulantes, cases à cocher, etc ...)

Sinon mes autres classes ne font que manipuler les données en lecture et écriture et ne génèrent pas de code HTML.


Question:

Dans le MVC à quoi ressemble les données transmises par le modèle à destination du contrôleur ?
- des chaines de caractères HTML rengéees dans un tableau puis justes incluses par la suite au squelette ?

Je vais rester schématique : dans un système MVC conventionnel, la partie HTML, c'est la VUE. Ça peut être par exemple un système de templates. Comme j'ai dit, c'est piloté par le CONTRÔLEUR. C'est le CONTRÔLEUR qui est défini par l'appel de la page par l'internaute. Si la page appelée doit être au moins en partie un formulaire, ton url permet de le définir et donc de sélectionner le modèle approprié pour récupérer les données nécessaires, ou encore de récupérer les données POST_DATA soumises lors de l'envoi de ce même formulaire.

Ta partie modèle, selon ce qui est défini dans ton CONTRÔLEUR, va enregistrer des données dans ta base, les modifier ou simplement en récupérer, puis retourner un résultat au CONTRÔLEUR. Selon le résultat reçu, le contrôleur va déterminer quel MODÈLE doit être appelé et avec quelles données variables à insérer dans le HTML.

Je me doute que tout ça est très théorique voire pas très évident à saisir. Si tu fouilles un peu le Net à la recherche de tutos sur le MVC, tu vas trouver quelques pages intéressantes.

Voila comment personnellement je procède avec Smarty :

La vue : les templates : du html, quelques boucles d'affichage, un peu de mise en page conditionnelle, ...

Le contrôleur : la page .php. Elle récupère les arguments et en fonction des arguments et déclenche telle ou telle suite d'actions en faisant appel à des fonctions.

Le modèle : la bibliothèque de fonctions php associée à la page : fonction insertion dans la base, fonction mise à jour, fonction d'écriture d"un fichier texte, ...

Pour chaque page, j'ai donc :
un fichier truc.php
un fichier truc.lib.php avec la bibliothèque de fonction
un fichier truc.tpl avec l'affichage (qui fait appel à un header, un footer, ...) ; parfois, il peut y avoir plusieurs templates en fonction de l'argument.

et bien sûr des bibliothèques communes pour définir les constantes de connexion, des fonctions utilitaires communes, ...

Merci pour vos réponses,

c'est un peut plus claire pour moi, il me semble que mon modèle peut être considéré comme du mvc.

Quel est selon vous l'avantage d'un moteur comme smarty ?

Euh, smarty n'est pas un MVC c'est un moteur de templates…