Reprise du message précédent :

 
A mon avis le monsieur aurait un soucis dès le premier point.
Dans la théorie à moins que je me trompe l'input utilisateur est traité par la vue.
Ca change pas énormément, mais normalement le controleur doit instancier la vue, et lui demander de lui fournir l'input utilisateur.

En ce qui me concerne, j'ai bien ma vue d'un côté et mon modèle de l'autre. La dessus aucun problème ils sont complètement indépendant et il n'y a pas d'échanges entre les deux.
 
En revanche, le contrôleur...
C'est justement ce qui avait été évoqué au début de ce topic, mon contrôleur finalement c'est mon script. Genre on appel la page register.php, et bien c'est le code contenu dans register.php qui va agir en tant que contrôleur. Je sais pas si c'est bien ou mal, et j'ai pas trop le courage de lire tout le topic pour voir si la question a déjà été évoquée...
 
Un avis sur la question?
Parce que très franchement je vois pas quel peut être l'intérêt de coder un contrôleur hors script...?

 
Je vois pas ce qui empêche de virer ça du contrôleur et de le mettre dans la vue.

C'est à peu près ce que j'ai fait chez moi. Par contre j'ai des crises d'identités dans mes Controller. Genre dans le cas du mail, le Controller instancie activement la view du mail, le créer, l'envoi, et redirige vers une URL de succès Est-ce que ce serait plutôt à la view de rediriger, elle qui sait le bon format ?

C'est masculin, comme rant d'ailleurs

C'est là pour moi la grosse différence GUI standard et GUI web. L'input utilisateur ne vient pas de la vue, mais de la requête. Le MVC traditionnel s'y casse un peu la gueule.
 

Cela va de soi. Le Controller est un peu un script PHP normal, mais mieux architecturé : sous forme de classe, avec des méthodes pouvant correspondre à la méthode HTTP ou à une action.

et alors?

Bon dans ce cas semblerait que j'ai bon, merci.
Je vais quand même continuer à suivre ce topic.

Je crois qu'on n'est pas sur la même longueur d'ondes, je reformule:
Les données fournies par $_GET, $_POST et autres => input
Les données fournies par le modèle => output
 

Je fais ça aussi. Mais je crois aussi qu'on gagnerait à rassembler ces deux actions ensemble.

Cet-à-dire qu'en web, on ne va pas instancier la vue pour lui demander les données. On va plutôt les récupérer d'un objet requête. La vue ne sert à rien dans ce cas là.

bah c'est bien ce que je dis.

Et pourquoi on ne le ferait pas? Et pourquoi ce ne serait pas la vue qui gère cet objet requête? Je vois pas ce qui dérange, en fait, là...et c'est ce que le mec veut dire - si tu veux changer d'interface utilisateur complètement (y compris la manière de récupérer l'input, donc), ben tu peux.

C'est justement la question posée. Le Controller doit-il récupérer les données directement de la requête, ou doit-il les récupérer d'une vue qu'il instancierait.

si tu veux faire du mvc strict comme dit le monsieur du lien cité plus haut, c'est le boulot de la vue.

En même temps (je réfléchis en live là), ce qu'on récupère dans la requête est directement lié à la vue. Vu que la vue, ça peut être un formulaire, et que la gueule du formulaire change directement ce qu'on retrouve dans la requête. Donc en récupérant les données de la requête, on récupère ce que la vue définit. Donc la question finalement ne se pose pas

Bah wala, c'est bien ce que je dis.
En manipulant directement l'input utilisateur dans ton contrôleur tu définis indirectement un contrat que devra suivre ta vue...tu n'es donc plus libre de la changer à ta guise, donc t'as niqué ton MVC.

OK. Dans ce cas, je ne suis pas d'accord que la vue reçoive ces données. Dans mon esprit, la vue ne peut recevoir que des informations provenant directement du modèle. C'est à dire des données qui auront été traitées, filtrées, etc.

Je vois là on mon implémentation est défaillante : certains trucs dépendants de la vue se retrouvent dans le contrôleur.
 
Genre les formulaires et les règles de validation : là actuellement le modèle définit les règles de validation. Ensuite le controller peut en rajouter par dessus (genre formulaire de connexion, champ "confirmer le mot de passe" ). Ce serait plutôt à la vue de faire ça, vu que c'est elle qui définit les contrôles.
 
Le contrôleur serait alors à sa place : récupérer les données (requêtes), récupérer les infos de validation, demander à la vue ses propres infos de validation, valider, et si tout est ok, hop on met à jour les données via le modèle.
 
Maintenant qu'est-ce qu'on fait une fois que c'est bon ? Comme en discutaient certaines personnes, c'est pas au controller de rediriger, mais plutôt à la vue.

 
Le problème c'est que la Vue ne reçoit pas l'input utilisateur - elle en est le propriétaire!

En même temps, la vue a parfois besoin de ces données : genre réaffichage d'un formulaire en cas d'erreurs, faut bien qu'elle réaffiche ce qu'il y avait dans la requête ?

Perso je pense que la validation de l'input doit être fait dans la vue.
Par contre les filtres qu'elle doit appliquer ne sont pas forcément tous définis chez elle : par exemple c'est le modèle qui sait quels champs sont obligatoires a priori. Par contre si la vue demande 2 fois le mot de passe c'est une validation que ne concerne qu'elle.
Pour moi le contrôleur récupère l'input déjà validé, et fait ce qu'il a à faire avec ça.

Effectivement. C'est ce que j'ai fait chez moi. Le modèle ne valide les données que de son point de vue. Genre type, taille, vérification si existe déjà, etc. Après la vue (chez moi le contrôleur pour l'instant, je vais modifier) rajoute ses propres règles style confirmation, etc.

C'est lui qui déclenche la validation, mais c'est pas à lui en fait de définir les règles de validations. Genre pour un formulaire de login :

class Users extends Model
{
 
  // ...
 
  public function getValidation()
  {
     $validator = new Validator();
     $validator->rule('login', 'string', 255);
     $validator->rule('password', 'string', 255);
     return $validator;
  }
 
}

Après la View définit ses propres règles :

class LoginForm extends View
{
 
  public function addRules(&$validator)
  {
    $validator->regle('password2', 'string', 255);
  }
}

Et enfin le controller réuni les deux :

class Login extends Controller
{
  public function httpPost()
  {
    $model = $this->model();
    $view   = $this->view();
 
    $validator = $model->getValidator();
    $view->addRules($validator);
 
    if($validator->check($this->post) {
      ....
    }
  }
 
}

Ainsi on peut changer le modèle et la view, rajouter des champs ou des validations, le controller restera le même, on a une séparation correcte

Il peut y avoir des validations à faire qui sont spécifiques à la vue (cf exemple de la double saisie du mot de passe par exemple). Pourquoi ce genre de validation se retrouverait-elle dans le contrôleur? Il s'en fout, lui qu'on présente le champ 1 fois, 2 fois ou 15 fois à l'utilisateur, ce qu'il veut c'est savoir ce que l'utilisateur a saisi.

Ensuite, qui a besoin de savoir ce qui n'a pas été validé? La vue, pour en notifier l'utilisateur.

Le contrôleur si l'input n'est pas bon il va se contenter de ne rien faire, de toute manière, à part demander à la vue de s'afficher.

class Users extends Model
{
 
  // ...
 
  public function getValidation()
  {
     $validator = new Validator();
     $validator->rule('login', 'string', 255);
     $validator->rule('password', 'string', 255);
     return $validator;
  }
 
}

class LoginForm extends View
{
 
  public function addRules(&$validator)
  {
    $validator->regle('password2', 'string', 255);
  }
}

class Login extends Controller
{
  public function httpPost()
  {
    $model = $this->model();
    $view   = $this->view();
 
    $validator = $model->getValidator();
    $view->addRules($validator);
 
    if($validator->check($this->post) {
      ....
    }
  }
 
}

http://www.djangoproject.com/documentation/newforms/
http://www.djangoproject.com/documentation/modelforms/

Comment il sait que l'input est pas bon, le contrôlleurs? Et si il veut simplement envoyer cet input au model, pourquoi la validation ferait-elle partie de la vue?

Il serait plus logique d'avoir la validation qui fait partie du model en permanence (model "virtuel" si besoin, sans backing dans une datastore)

 
Maintenant question (si tu connais bien Django bien-sûr), à quel niveau gèrent-ils les redirections. Genre si les données sont valides et sauvegardées, est-ce le controller qui décide quoi faire, ou la vue ?

T'as vu des buses qui utilisent symfony alors
Le passage de données du controlleur à la vue par contre se fait effectivement en remplissant en dynamique des données membres du controleur. Je vois pas trop en quoi c'est pas clean

C'est le rôle du contrôleur de gérer ça. Il reçoit les données, les file au modèle pour validation et ensuite a un comportement suivant le résultat de cette validation.

Comme je le vois, tout ce qu'il saura c'est que quand il demande l'input à la vue cellec-i ne lui retourne rien, puisque ça n'a pas validé. Donc il n'a rien à faire.
 

 
Toutes les validations à faire ne concernent pas le modèle...pour moi le modèle doit bien être le propriétaire de certaines règles de validation, mais ce n'est pas à lui de les tester directement sur l'input utilisateur.
Donc soit le contrôleur peut lui demander les règles et les transmettre à la vue, soit chaque couche fait les validations qui lui sont propres elle-même, mais dans ce cas il faut un mécanisme de remontée du résultat des différentes validations vers la Vue un peu plus complexe...
 

Justement, ça à l'air d'en faire sauter quelque-uns...

 
La vue est censée être une représentation de l'état du modèle, pas du contrôleur.
 
Puis bon bref, je trouve ce genre de déclaration implicite de variables immonde en général, de toute manière.

Tout ce que doit faire le controleur une fois qu'il a traité ce qu'il avait à traiter, c'est demander à la vue de s'afficher.

Et donc elle redirigerait éventuellement vers une page de succès ou vers la liste des enregistrements...

Django ne se définit pas comme un framework MVC (surtout pas strict), mais comme un framework MTV.
 
Donc dans Django les redirections (ou même l'appel aux routines de validation) sont effectuées au niveau de la View, mais dans la majorité des frameworks c'est une étape qui correspond plus au Controller.

Voilà, c'est elle qui choisit ce qu'elle doit présenter à l'utilisateur. En tout cas c'est comme ça que je vois un MVC "strict".

Ok je vois. Je constate qu'ils ont une très bonne approche, c'est très pragmatique tout ça (et donc sûrement supérieur au reste).
 

Ouaip, je commence à comprendre. Je vais me rentrer chez moi, et y réfléchir sur la route, compte rendu dans une heure

Ca reviendrait pas un poil à ce que je disais sur la vue dans un mvc "strict", ça?
Depuis tout à l'heure que j'y réfléchis je me dis qu'il y a de moins en moins de trucs dans le contrôleur et qu'on pourrait tout autant le résumer à une classe qui se contente de choisir la bonne vue et les données associées...

Si. Va lire le lien que j'ai filé à florangé sur la faq django

(en gros, ils considèrent que le controller c'est le dispatcher d'URLs + quelques trucs autour qui font globalement partie du framework, donc le controller n'est pas défini par l'utilisateur, qui définit le modèle, la vue et la/les template(s). D'où MTV Model Template View)

Oué ok, donc c'est un framework MVC dont une partie du C est dans le framework lui-même et le reste tellement léger qu'il a été fusionné dans la vue, quoi.

http://www.aide-de-camp.org/articl [...] attern-mvc

Détail : dans tous les cas en MVC, la template fait bien partie de la vue nan ?

 
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.