Bonsoir,

Je suis actuellement en train de développer une application web basée sur le MVC, tout fonctionne bien sauf que je bloque sur un détail : J'ai des formulaires à valider, pour faire ça, j’utilise un contrôleur, celui-ci vérifie les champs de mes formulaires, s'ils sont bons, il les passent au model pour l'insertion dans la base données, si en revanche, les champs ne sont pas bons, le contrôleur passe les messages des erreurs à la vue, et le contrôleur affiche à nouveau le formulaire plus les messages d’erreurs.

Cette procédure est valable ou c'est le model qui doit valider les formulaires ?

Merci d'avance pour réponse.

Dans le meilleur des mondes je dirais que c'est au modèle de valider les données. Seulement, je me suis mis à Zend Framework, et je pense tout simplement migrer ma bdd vers PostgreSQL qui fera une vérification ultime des données par toutes contraintes, et laisser les validateurs Zend faire leurs boulots. Cela dit, pour éviter la dispersion, je pense faire comme un tuto que j'ai vu, c'est à dire enregistrer mes formulaires dans un dossier de modèle. Ainsi, mon contrôleur charge le formulaire, l'affiche, gère les données entrantes et appelera certainement une méthode du formulaire qui validera les données, et mettra à jour. Le formulaire est donc un peu à mis chemin entre controleur et modèle, mais l'organisation changera la donne. Ainsi, globalement, seul un formulaire éditera des informations, alors que le controlleur pourra éventuellement en supprimer. Pour assurer un max de cohérence, je vais donc modéliser mes données, créer mes contraintes côté base de données, et ajouter des validateurs identiques côté PHP.

J'avais pensé à mettre des validateurs, filtres, et valeurs (enum etc) côté modèle, avec un controlleur qui construit un formulaire à partir de ces informations, mais quoi que je fasse, tout se chevauchait et c'était le grand merd*er. Au final, la conception aurait perdu tout l'avantage que fournit Zend.

C'est toujours difficile de placer les contrôles, chaque framework a sa propre logique à ce sujet..

De mon point de vue, les contrôles de surfaces (format des champs, présence/absence, etc.) doivent être placés dans les modèles ; en revanche les règles de gestion (qui nécessitent généralement l'utilisation de plusieurs modèles) sont à placer dans les contrôleurs. Après, c'est à toi de voir ce qui te parait le plus clair.

Salut Mox,

Il me semble que, globalement, la démarche que tu implémentes est tout à fait correcte.

Personnellement, je procède de la façon suivante :

Dans l'action (du contrôleur) :

• Je commence par déterminer si le formulaire doit être affiché pour la première fois. Pour cela, j'inclus dans le formulaire un champ caché qui contient un "identificateur de formulaire". Tous les formulaires de mon application présentent un "identificateur de formulaire" unique. Il s'agit d'une simple chaîne de caractères. Si ce champ caché est absent da la liste des valeurs envoyées à la page courante, cela signifie que le formulaire doit être affiché pour la première fois. Sinon, cela signifie que l'action (du contrôleur) couramment exécutée doit traiter les données envoyées par le formulaire.
• Dans le cas où le formulaire doit être affiché pour la première fois, l'exécution du contrôleur s'interrompt. J'affiche la vue associée au formulaire.
• Dans le cas contraire, l'action (du contrôleur) vérifie la validité de chaque champ envoyé par le formulaire, pris individuellement.
• Si des champs présentent des erreurs, l'exécution de l'action (du contrôleur) s'interrompt. J'affiche la vue associée au formulaire. Le décorateur associé au formulaure se charge du rendu des messages d'erreurs individuels à chaque champ.
• Si tous les champs sont individuellement valides, l'action vérifie la cohérence de l'ensemble des champs.
• Si les champs sont incohérents dans leur ensemble, l'exécution du contrôleur s'interrompt. J'affiche la vue associée au formulaire. Le décorateur associé au formulaure se charge du rendu des messages d'erreurs individuels à chaque champ. Et, via un mécanisme propre à la vue, j'affiche un message d'erreur général (qui n'est pas lié à un champ en particulier).
• Si tous les champs sont cohérents entre eux, l'action (du contrôleur) procède à l'utilisation des données envoyées par le formulaire. Cette étape implique le plus souvent l'utilisation d'une "passerelle" (mapper) vers le modèle de donnée.
• En fonction du status de l'utilisation de la passerelle vers le modèle de données, trois réactions sont possibles :
  • Je réaffiche le formulaire.
  • Je change la vue associée à l'action courante, de façon à afficher une vue spécifique (autre que celle associée au formulaire).
  • Je lance une redirection (vers une action différente de l'action courante).

A+

Ce dernier cas est plutot banale pour un framework de type Zend, du moins de la faible expérience que j'en ai. Par contre, à aucun moment le modèle n'a le dernier mot sur les données, et c'est pourtant lui le responsable. Effectivement, l'utilisation d'ORM, j'ai l'impression, induit une modification des données via l'ORM au sein même des controlleurs.

L'idée de départ était d'avoir un modèle Table_X. Celui-ci possède un ensemble de champs, et lié à chacun une liste de validateurs, filtres, etc. Mais c'est un peu RubixCube, si le controleur vient chercher les éléments, il peut très bien les modifier, et appeler une méthode du modèle pour modification des éléments, ce qui revient à prendre des risques de validation. Je reviendrais là dessus, mais finalement, une bonne organisation est peut-être mieux qu'une architecture trop rigide. L'idée étendue est que le validateur ne soit plus dans le formulaire controleur mais soit rajouté une fois le formulaire transmis au modèle. Mais les avantages que proposaient l'autre idée sont échangées avec d'autres. On peut aussi avoir des validateurs, et une fois au modèle, les redéfinir et faire une double verifications. Bref, j'ai tournée ça tout le temps, je n'ai eu aucune solution miracle si ce n'est celle de créer mon framework à partir d'une de ces idée. Blague ...

Finalement, mon soucis finale et cela a toujours été mon soucis est l'aspect global de "cohérence", et c'est ce qui m'avait tourné vers PostgreSQL même si j'avais renoncé. En fait, on peut subsituer le travail de l'un et de l'autre (modèle - sgbd). Soit les validations finales se font coté php, soit coté sgbd. Si ce n'est que le sgbdr, ... c'est vraiment son job. Et là, tout a repris un sens plus commode. Bien sûr ... organisation. Donc mon premier job va être de modéliser l'ensemble des tables, et de créer des règles pour chaque (ex: utilisateur doit respecter /^[a-z0-9_-@\.]$/i ). Puis de créer un repertoire sous models/ pour chaque table, donc lequel j'ai le "mapper", et les formulaires liés. Ca évite de se disperser.

C'est en gros le gros soucis de PHP. Les tutos de Google sont vieux, les méthodes vieilles ;p Et il est plus facile de trouver un tuto sur comment faire un code sale qu'un bon MVC. Sur d'autres langages, le soucis est un peu plus différent puisque dès le départ ils ont dit : pas de néophytes, pas de procédurale, voire pour certains (je ne vise personne ^^) : que du framework.

Cette dernière phrase est un peu troll : sans commentaire.

La vérification des informations reçues par le formulaire doit se faire en toute logique dans le contrôleur, pour qu'il décide ensuite d'afficher les erreurs (dans la vue) ou d'enclencher le traitement des informations (dans le model). Le MVC c'est cool, mais au final c'est vrai qu'on sait rarement comment utiliser les contrôleurs à bon escient.