Reprise du message précédent :

 
Si on résume, il dit ça :
M = classes de validation.
V = classes qui savent afficher les formulaires.
C = classes de formulaire elles-mêmes.
 
Problème :  
C'est bien joli tout ça, mais il a encore une couche entre le contrôleur et la vue qui vient taper dans les deux sans demander l'avis de personne => son action!
Soit elle fait partie du contrôleur et dans ce cas elle n'a pas à aller taper dans l'input utilisateur directement ou à balancer une redirection de son choix, soit elle fait partie de la vue et dans ce cas elle n'a pas à instancier le contrôleur.

oui.

Je pense que je vais laisser la redirection dans le Controller. C'est quand-même quelque chose d'assez spécifique au web justement cette histoire de redirection.
 
Genre si vous avez besoin d'une application qui liste des enregistrement et permet d'en créer. Va y avoir deux contrôleurs : un pour la liste, l'autre pour l'ajout. Un modèle, et deux views (avec leur templates respectives).
 
Lorsqu'on on insert un nouvelle enregistrement (donc quand on utilise le contrôleur d'ajout), c'est le contrôleur qui va sélectionner les différentes actions à faire. Si appel via méthode GET, on affiche le formulaire. Si méthode POST, on va valider les données, et ensuite deux options :  

• Données valides, on les file au modèle pour qu'il les insert, puis on redirige vers la liste
• Données pas valides, on réaffiche le formulaire avec la liste des erreurs.

Notez la subtilité entre "affichage" et "redirection." Dans les deux cas, c'est le Controller qui sélectionne la view à afficher, c'est pas à la view du formulaire de décider d'en afficher une autre ().

Dépend de ta façon de voir les choses, tout ça.
Tu ne raisonnes pas avec LA vue, mais avec DES vues...alors que pour une séparation stricte des couches le Contrôleur n'a pas à savoir ce qui se passe en interne dans LA vue...
Perso la partie de la vue visible de la vue pour le controleur je la vois grosso-modo comme une factory de tes vues, si tu veux rester strict.
Et le contrôleur ne redirige pas, il demande juste à l'objet que la factory lui a refilé de s'afficher.

Ouais ça c'est sûr. Surtout avec un truc comme MVC qui ne donne que les grandes lignes.
 

Ouais je vois. Je vois je vois je vois.
 
Genre ton contrôleur ne ferait qu'instancier des vues. Après la vues fait ce qu'elle veut : soit elle s'affiche cash, soit elle redirige vers une autre URL.
 
Genre une implémentation rapide :

class MyController extends Controller
{
  public function execute()
  {
     $form = $this->getView();
 
     if($form->valid($this->request->getPost()) {
 
       $this->model->save($form->data);
       $this->render('view_succes');
 
     } else {
 
       $this->render($form);
     }
  }
}

 
Après la view_succes est libre de faire ce qu'elle veut : rediriger, afficher une page, etc.

Nan, j'irais encore plus loin.
 
En très gros, carrément ça :
 

class MyController{
    
    function execute(){
        $this->view = ViewFactory::getView();
        $this->updateModel($this->view->getInput());
        $this->view->render($this->model);        
    }
    
}

Ah ouais... C'est peut-être un peu extrême, nan ?
 

Un peu j'trouve. Surtout que là il laisse la vue décider de quoi faire (selon que les inputs sont valides ou non), or pour moi c'est de la "logique" ça, donc plus du boulot du Controller.

La discussion porte justement sur le fait que le contrôlleur n'a pas à implémenter la moindre logique, ni métier (qui va dans le model) ni autre (qui irait donc dans la vue)

Bon excusez mes questions de noob, mais si c'est le model seul qui doit implémenter la logique, alors il s'occupe non seulement de l'accès à la base, mais aussi à la session, à l'input, et à tous calculs en tous genres ? je croyais qu'il était généralement cantonné à la BDD...
 
2eme question de supernoob celle-là : là vous parlez de model et de view comme si il n'y avait qu'une seule view et un seul model par page, pour la view ok, mais vous n'utilisez jamais plusieurs models par page ?
 
Hypothèse de réponse à mes 2 questions : le model est-il divisé en plusieurs couches (genre une qui s'occupe de chaque page, et une qui s'occupe de l'accès la BDD) ?

Quand on parle de model, on parle de couches dans la hiérarchie MVC, pas de classe précise dans le modèle.

oué j'ai bien compris ça, mais ma question demeure

En fait je pensais jusque là que le model s'occupait de l'accès aux données, le controleur (front + autres) de la couche métier, et la vue l'affichage...

Mais pitetre que je devrais lire plus

Enfin en gros y contrôle plus rien là alors, ca joue grosso modo le role d'un "dispatcheur" : "opla récupère ça et balance le à ça".
Ca me parait vraiment extrême comme point de vue quand même.
 

Si. Genre dans une boutique, lors de l'affichage d'une catégorie, j'ai besoin du modèle catégorie, mais aussi du model produits pour en afficher la liste. Là c'est à ton Controller d'instancier les bons modèles dont la view a besoin

Du coup c'est bien le controleur qui s'occupe de la couche métier/logique. Mettez-vous d'accord avec Masklinn

Enfin ce que je vois aussi c'est que la plupart du temps ya un menu et plein de données extérieures dans une page, qui sortent de BDD donc du model... Mais le fait d'afficher ces trucs là c'est plus la responsabilité de la vue (puisqu'en RSS pas de menu, par ex)

Non, il ne fait qu'instancier les bons modèles, et ça s'arrête là. La couche métier, c'est bien le modèle qui s'en occupe.

Y sont d'accord, vu que c'est une DISCUSSION, donc de savoir si oui ou non faut que le contrôleur se tourne les pouces ou non

bof

Ben non, le controller dispatche simplement les données utilisateur à la vue ou au model, qui vont implémenter les différentes phases de la logique

http://c2.com/cgi/wiki?WhatsaControllerAnyway

Apparement une redéfinition/réinterprétation du terme est arrivée par la suite (cf suite de l'article), mais la définition originelle correspond à un objet extrèmement limité en capacités et en complexité.

bah si tu veux vraiment séparer les couches, hein...
Bon après je ferai jamais ça dans la vraie vie, entendons nous bien, ça m'apporterait rien.

Il se tourne pas les pouces. Il demande à la vue quels événements se sont produits, et en fonction de ceux-ci appelle les modifications qui vont bien sur le modèle.

Alors j'ai encore réfléchi toute la matinée, je suis arrivé à certaines conclusions.
 
J'me suis baladé à droite et à gauche, sur c2.com et wikipedia, et j'ai lu l'implémentation MVC de Cocoa, et de différents frameworks PHP.
 
Je constate que le MVC « standard » est difficilement applicable en web, vu que la vue finale sera une page HTML. Impossible de faire une vue vraiment active, tout doit passer par une requête au serveur, et donc passer par un contrôleur.
 
Pour cette histoire de redirection, je constate qu'elle sont généralement obligatoires après toute requête POST : on redirige, via un 303 See Other, vers une ressource résultante, donc on redirige vers un contrôleur. Ce qui donc ne me pose pas de problème à faire la redirection dans le contrôleur; ce contrôleur va transférer en quelque sorte à un autre contrôleur la tâche de gérer l'action à faire.
 
Le contrôleur « succès » va pouvoir afficher la liste des enregistrements avec un message supplémentaire, ou afficher une page genre « bravo, insertion avec succès ». Dans tous les cas, ce contrôleur doit être lancé via une redirection. Ce qui définit du coup le rôle de la view.
 
La vue sera donc assimilée à une « page ». Le seul rôle de la vue sera de récupérer le model, plus quelques options éventuelles, et de préparer à partir de tout ça des données pour la template. Elle ne peut donc pas gérer d'eventuelles redirection, elle ne s'occupe que d'une page donnée.
 
Après on aura un type de vue spécial pour les formulaires, qui inclura en plus des règles de validation.
 
Le contrôleur va donc avoir pour rôle de choisir les actions à réaliser en fonction de la requête et de l'état de l'application :

• Requête GET, on instancie le model, on le file à la vue et pis voilà
• Requête POST, on instancie le model, on le file à la vue, on demande à cette vue de valider les données. Si données pas valide, rien (la vue se réaffiche). Si les données sont valides, on les sauvegarde via le model, et on appelle un autre contrôleur via redirection qui saura quoi faire.

Se pose encore le problème de la requête : y'a la différence entre les données de la requête, et les paramètres de la requête (d'un point de vue protocole, le premier représente les données POST, l'autre l'URL et ses paramètres éventuels). Qui va valider les paramètres ? Quand on veut éditer un enregistrement, on va mettre dans l'URL l'identifiant de l'élément. Qui donc va valider cet identifiant. Qui va dire « enregistrement pas valide, on balance une page avec message d'erreur ».
 
Là pour moi c'est au contrôleur de faire ça. C'est lui qu'on cible via une requête, c'est à lui de valider les paramètres transmis via l'URL.
 
On obtient donc ce schéma de fonctionnement (exemple avec une requête POST pour modification d'un enregistrement) :
1) Une requête HTTP arrive (genre /edition.php?id=123)
2) On instancie le contrôleur correspondant
3) Le contrôleur instancie ce dont il a besoin (model, view, etc).
3) Le contrôleur vérifie que les paramètres de la requête sont bon : il demande au modèle si l'enregistrement existe bien. Si ok, on continue, sinon il lève une exception.
4) Le contrôleur demande à la vue de valider les données de la requête. Là on peut utiliser un objet de validation, qui sera récupéré par la vue via le model. La vue y greffe ses règles de validation et vérifie les données.
5.1) Si les données ne sont pas valides, on réaffiche la vue, qui se chargera d'afficher les éventuels messages d'erreurs.
5.2) Si les données sont valides, le contrôleur les file au modèle qui se charge de les sauvegarder. Le contrôleur redirige alors vers un autre contrôleur qui gèrera le succès de l'opération : page spécial de succès, réaffichage des enregistrements avec un message "flash", etc.
 
Avec ça, je pense avoir une bonne séparation des couches, et une structure respectueuse du protocole HTTP.
 
Bon après, pour certains trucs je pense aussi faire des contrôleurs « lightweight » : parfois on a besoin dans un site de petites boîtes spécifiqueq, genre affichage d'un produit en promotion, etc. Faire une grosse architecture MVC comme au-dessus risque d'être lourdingue, on peut implémenter des contrôleurs qui parlent directement à une template. Ils instancient un modèle, récupèrent des données, et les communiquent directement à une template.
 
A vos réfléxions et vos avis !

Ben non, suffit de considérer (comme le fait django) que le rendu HTML n'est qu'une partie de la vue, et qu'il y a du code backend qui en est une autre partie

edit pour préciser: je lis même pas le reste, qui est basé sur ces prémices complètement fausses.

Je parlais vraiment d'un point de vue traditionnel, dans le style "la vue souscris à des évènements du modèle." On peut toujours après mapper certains concepts.  
 

Dommage, j'aimerais bien ton avis sur certains points que j'ai soulevé...

Dans ma logique, c'est le modèle. Il reçoit, valide, traite, c'est lui qui décide du sort des données. Il va jusqu'à décider si elles peuvent être lues (privilèges).
 

Chez moi, tout passe par le modèle. Le modèle est pratiquement l'application.

Comment fait-tu pour les règles de validation propre à un formulaire, mais pas au modèle ?
 

Oui, c'est le point majeur du speech de l'autre :

tu lies ton modèles à l'interface utilisateur, donc...ça a plus rien à voir avec du mvc, là...

Oui, c'est vrai que mon modèle est fortement lié à l'interface utilisateur, l'application que je construis est prévue comme ça depuis le début. Ceci dit, si je dois être amené à valider plusieurs modèles différents (cas envisageable dans ce que je fais), ce n'est pas un problème. Je demande à chaque modèle de se valider (ce qu'il ferait de toute façon à la sauvegarde), et si le contrôleur détecte des erreurs dans la file des erreurs, il les affiche (éventuellement avec le formulaire pour corriger).
 
Pour le crazy guy, je dois bien avouer que son article me confortait dans mon idée du MVC

Maintenant comment sont définis tes modèles ? Quelles entités représentent-ils ?
 
Est-ce que les spécificités liés à des formulaires sont aussi validées dans le modèle ?

Chaque classe modèle est attaché à une table. C'est une règle, mais pas une obligation (mon modèle utilisateur exploitera plusieurs tables). C'est l'état actuel de mon travail mais ce n'est pas encore définitif, je suis à un stade de prototype.
 
Je constate en y réfléchissant que j'ai encore quelques soucis à résoudre. Par exemple, la gestion de mots-clé, j'ai pas envie de me taper une instance de classe pour chaque mot-clé, et comme je peux faire de l'insertion multiple en MySQL, je ne vais pas m'en priver.
 
Quand tu dis spécificité, tu penses à quoi?

C'est ce que je fais aussi en général. Maintenant si t'as des trucs splittés en plusieurs tables, c'est un peu relou niveau perfs.
 

Les règles de validations qui ne concernent que les formulaires, mais pas les modèles. Comme on en a parlé avant, genre un formulaire d'inscription, le champs "confirmer le mot de passe" est spécifique au formulaire, mais le modèle s'en fout. Il veut un login et un mot de passe pour créer un utilisateur.

Ca serait peut-être encore plus relou si je ne les avais pas splittées Note qu'en InnoDB, cet argument tient peut-être moins la route. C'est surtout une question d'accès à certaines fonctionnalités, qui fait que l'entièreté du profil utilisateur n'est pas indispensable au chargement. Je pourrais mettre ces champs en null par défaut...
 

Ah oui, j'ai un tel formulaire en plus  Fonction spéciale dans le modèle utilisateur pour changer de mot de passe. C'est un cas exceptionnel pour moi, je le traite comme tel.

 
A lire : My framework is more MVC than *your* framework!

 
J'ai une impression de déjà-vu

article peu intéressant à mon avis, l'auteur ne fait qu'exprimer ses idées de manière très vague...ça n'apporte pas grand chose par rapport à l'article précédent et notamment ses commentaires...

Pour supprimer un article de ma BDD, j'appelle le contrôleur "product/del" qui lui va charger le modeèle, qui va supprimer les informations.
 
Mais pour supprimer les images attachées à un article, c'est dans le modèle aussi ?
 
Je suppose que ce n'est pas dans le contrôleur, ça fait redondance suivant ce qu'il y a à supprimer. Mais j'ai toujours dans l'esprit que modèle = BDD
 
Donc je voudrais juste confirmation

Moi, je verrais plus les choses comme ça :
 
Modèle = données (que ce soit bdd ou non). Les images liées à l'article, ce sont des données, donc ça passerait par le modèle !

Le css lié à la page c'est des données, c'est dans le modèle aussi alors

rien à voir. Les images peuvent être de l'information. Les css c'est de l'affichage.

Merci skeye.