Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Cette discussion est très intéressante et je pense qu'il y a autant du vrai que du coté de sekaijin que de Guardian_7.
Notez que Zend_Form vient d'entrer en "review" :
http://framework.zend.com/wiki/display/ZFPROP/Zend_Form
J'y ai laissé un commentaire ("best practises to reuse validation rules". ) en relation avec cette discussion.
Si vous avez de bonnes idées je pense qu'il ne faut pas hésiter à commenter.
pour illustrer mon propos mon modèle utilise des dates
ces dates sont des objets
mon application présente un formulaire avec trois sélect box
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
quoi qu'il arrive si mon contrôleur ne donne pas un objet construit avec les trois valeurs des selectbox mon modèle répondra invalide
je pourrais adapter mon modèle
mais alors mon modèle dépends de la vue
et si ma vue évolue je devrais encore changer mon modèle.
si c'est le contrôleur dont le rôle est d'orchestrer les échanges entre la vue et le modèle qui se charge de ce travail l'évolution de la vue implique une adaptation du contrôleur mais pas du modèle.
inversement mon modèle évolue et je n'utilise plus un objet à trois champs pour mes dates mais une chaîne. le contrôleur est adapté mais pas la vue.
lorsque j'internationalise mon application il me parait logique de formater les date issue du modèle dans un format compréhensible de l'utilisateur. et il est évident que ce n'est pas le modèle que le fait. c'est le contrôleur. le métier ne change pas parce que je suis passé en français espagnol ou japonais
je ne vois pas pourquoi il en serait autrement dans l'échange inverse c'est à dire entre la vue et le modèle. c'est le contrôleur qui récupère les données de la vue dans la langue de l'utilisateur c'est lui qui sait dans quelle langue travaille l'utilisateur et c'est lui qui sait quel type de donnée attend le modèle.
je ne comprends pas qu'on veuille reporter ce travail au modèle.
Je travaille dans une équipe et ce n'est presque jamais les même personnes qui s'occupe de cœur de métier, de la logique applicative, et de l'IHM
on défini donc une API au niveau du modèle et les contrôleurs mais aussi les webservices doivent tous s'y conformer sans ça THROW MODEL_EXCEPTION
pareil pour le modèle il doit respecter le contrat (API)
de même on définit les échange (l'API, le protocole) entre la vue et le contrôleur. et chaque équipe doit s'y conformer. si la vue ne se conforme pas
le contrôleur lève une exception, de même si le contrôleur ne donne pas à la vue ce qu'elle attends celle-ci plante.
et on peut mettre en place tous les mécanisme que l'on veut si tu appelle une fonction qui attend un entier avec un chaîne ça plante et c'est normal.
quant à mon exemple sur le filtrage des valeur numérique. en php ça parait pas très évident vu que le langage est faiblement typé.
mais avec un autre langage si ta fonction de validation attend un entier tu te fais jeter avant même d'avoir tenté de valider ta donnée et c'est bien au contrôleur de s'assurer que ce qu'il donne au modèle est SYNTAXIQUEMENT correct le modèle s'occupant lui de la validation SÉMANTIQUE.
Maintenant je comprends que lorsqu'on est seul ou peut nombreux, et que l'on maîtrise de bout en bout on prenne des facilités. la lecture d'un entier dans un champ relève de l'analyse syntaxique et la vérification que l'entier lu est conforme au métier de la sémantique.
séparer les deux améliore grandement la robustesse et l'evolutivité ainsi que la réutilisabilité. mais cela fait faire plus de travail au moment du développement.
et je comprends très bien qu'on décide de donner directement la chaîne de caractère à la fonction qui doit vérifier que le paramètre est bien compris entre 0 et 100, mais il faut être conscient que celle fonction du modèle implique une dépendance à la vue chose que le modèle MVC cherche à minimiser.
A+JYT
Le choix de la "facilité" c'est d'appliquer des principes de conception empiriques, voir arrivistes au detriment de processus éprouvés.Envoyé par sekaijin
Lorsque je développe une application orientée objet, je commence par analyser le problème dans sa généralité (et dans la possible réutilisation des solutions), je ne pars pas d'une situation particulière ou d'un cas d'utilisation conret.
Dans la phase de conception, j'essaie d'appliquer des solutions éprouvées ou a priori académiques, et ensuite seulement, je me préoccupe des problèmes d'implémentation.
Apparement c'est la base de nos divergences sekaijin...
...Il s'agit simplement de respecter un motif de conception, dans l'intéret commun du développeur et du client... Ce n'est pas parceque c'est PHP et qu'il s'agit de développement Web, qu'il faut partir dans tous les sens.
Bref.
Démontre-moi clairement que tes solutions sont meilleurs, par rapport à ZF, son modèle MCV et ses modules de filtrage. Si possible sans t'écarter du sujet...
justement je ne pense pas que se soit partir dans tous les sens que de bien cibler ce qui relève du métier de ce qui relève de son usage.
pour moi le métier et un bloc bien définit avec une api claire qui ne dois avoir à être modifié parce qu'on l'utilise ici où là.
donc lorsque ma MOA me dit que la règle c'est celle là mon métier implémente la règle rien de plus.
et si ma MOA me dit que veut changer la présentation des données je ne veux pas avoir à toucher à mon modèle.
et si demain elle me dit que mon application doit d'interfacer avec une autre je ne veux pas avoir à toucher à mon métier.
J'applique donc des pattern logique et éprouvé
la vue présent
le contrôleur contrôle
et le modèle traite
Meyer à qui on doit de nombreux travaux sur la POO à surtout introduit un truc qu'on n'utilise pas assez qui s'appelle la programmation par contrat
en clair lorsque tu fait un objet une méthode un package tu définit une interface une API de fait de définit un contrat avec le développeur qui veut l'utiliser. s'il ne respecte pas le contrat il n'y a aucune raison de chercher à traiter sa demande. ces à lui de faire le nécessaire pour bien utiliser l'API.
lorsque je développe je considère que je passe un contra avec les développeurs des fonction et objet des librairie que j'utilise et c'est à moi programmeur de faire en sorte que je les utilises correctement.
et lorsque je fais appel à une fonction php je la prends comme elle est. je ne lui demande pas de s'adapter à tout les types et valeurs possible de tout et n'importe quoi.
lorsque j'appelle une fonction qui demande un entier je m'assure de lui donner un entier. et si elle veut une chaîne je lui donne une chaîne.
lorsque je veux ouvrir un fichier en écriture je m'assure que le paramètre que j'utilise est bien une chaîne de caractère.
puis je demande à l'API de me dire si oui ou non du point de vu de son métier de gestion de fichiers ma chaîne est valide pour ouvrir mon fichier. et enfin je demande au métier de faire le boulot c'est à dire d'ouvrir le fichier.
si je donne un tableau ou un entier à fopen je vais me prendre une exception et c'est normal c'est à mois de vérifier ça avant. une fois que je l'ai vérifié je peux alors demander au métier de me valider ma donnée is_writable
pour moi entre le contrôleur et le métier on est exactement dans ce cas.
le contrôleur s'assure que ce qu'il donne au métier est bien ce qu'il attend lui demande de valider sémantiquement la donnée et lui demande de la traiter.
c'est le schema que l'on trouve partout dans la programmation
à chaque fois que tu appelle une fonction que tu utilise un objet utilise un protocole.
je ne vois pourquoi j'irais inventer un truc à alors que cette façon de faire est éprouvée robuste évolutive et réutilisable.
A+JYT
Bonjour,
Je pense un peu comme sekaijin.
Il faut distinguer la validation/filtrage technique de la validation/filtrage fonctionnel-métier.
La première répond à des problèmatiques techniques, elle est à la charge du controleur, et est chargée de valider/filtrer les données pour qu'elles répondent au contrat que constitue l'API du modèle (typiquement par exemple transformer les chaines de caractères de type "jj-mm-aaa" en objet de type Date qui va contenir des champs jour; mois; année si le modèle attend une Date).
La deuxième valide les données pour répondre à la logique métier, les erreurs retournées par cette validation sont des erreures propres aux métiers ("Date invalide car il existe deja un rendez vous ce jour là").
Le modèlé ne devrait pas lever d'erreur du genre "La chaine de caractère saisie ne correspond pas à une date valide" si la date saisie par l'utilisateur est 37 juin 2007. Il s'agit là d'une validation technique.
L'apologie du filtrage, je pense qu'on en a fait le tour au moins 3 fois. La question c'est son application dans le Zend Framework.
J'attends toujours qu'on me démontre l'efficacité (l'utilité) évidante des filtres au niveau d'un contrôleur d'action.
Le reste relève visiblement du mono-dialogue...
La question, même si ici concerne le Zend Framework, est tout de même une question relative à la conception logicielle. Elle concerne particulièrement la responsabilité du filtrage/validation des données en provenance d'une vue dans le cadre d'une application MVC.L'apologie du filtrage, je pense qu'on en a fait le tour au moins 3 fois . La question c'est son application dans le Zend Framework.
L'efficacité réside dans la robustesse de la conception : une indépendance du modèle par rapport à la vue.J'attends toujours qu'on me démontre l'efficacité (l'utilité) évidante des filtres au niveau d'un contrôleur d'action.
Et pour répondre à la question initialement, à savoir : qui se charge du filtrage des données dans une application MVC ? Je dirai le modèle et le contrôleur, tout dépend si ce filtrage répond à une logique métier ou non.
Si tu lis les précédents messages, tu devrais constater qu'on a effectivement causé conception, et qu'on a tourné en rond
J'essaie simplement de recentrer le sujet sur des choses un peu plus constructives.
On est d'accord là-dessus.
Je repète ma question, en quoi le fait d'introduire des filtres au niveau des contrôleurs d'action est utile, efficace, réutilisable en fin de compte ?
Et pour répondre à la question initialement, à savoir : qui se charge du filtrage des données dans une application MVC ? Je dirai le modèle et le contrôleur, tout dépend si ce filtrage répond à une logique métier ou non.
Je précise : Je parle bien des contrôleurs d'action du Zend Framework.
ça ne change rien en terme de rapidité
de toute façon tu vas faire un test pour vérifier le type (le format) et un autre pour le métier
que tu mette ça dans une fonction ou deux fonction ça ne changera rien.
le seul truc c'est que si tu les sépare un rend ton modèle moins dépendant de ta vue et donc potentiellement plus réutilisable. de même ta vue étant moins dépendante du modèle elle est plus évolutive et plus robuste.
tu va y gagner aussi en terme de partage du travail.
et pour finir tu peux généraliser le contrôleur au moins en partie.
tu vas donc être plus efficace dans tes développements. mais ton code lui devra de toute façon faire les deux vérifications. ne sera pas plus rapide.
A+JYT
Je suis d'accord avec toi sur le fait qu'il n'y aura pas de différence significative au niveau du temps d'exécution. Ce n'est pas un facteur très important à ce niveau.
Plus réutilisable, je ne suis pas d'accord. En suivant ton raisonnement, il faudrait copier systématiquement les régles de filtrage dans chaque contrôleurs d'action (ça a déjé été dit précédement).
Généraliser tout ou partie du contrôleur pour des tâches de filtrage serait inaprorié...
Si le travail est réparti entre plusieurs développeurs, ils devront connaître les spécifications du modèle (les régles de validation Zend_Validate) ainsi que les régles de filtrage (Zend_Filter) figurant dans les contrôleurs et qui peuvent varier...
Je pense que séparer l'implémentation de ces deux modules n'est pas un signe de robustesse pour l'application.
Zend_Filter_Input a été créé dans le but de regrouper ces deux modules et donc ces deux operations. Ce n'est pas par hasard...
...Si une classe métier implémente Zend_Filter_Input, il suffirait d'étendre la classe en question pour en modifier ses régles de filtrage ou de validation. Ca me semble être l'approche orientée objet la plus rationnelle.
lorsque j'ai un crud à faire je crée un contrôleur qui dérive d'une classe crudAction comme la Zend_controller_action
je lui donne une référence à mon modèle et le nom des méthode d'enregistrement de recherche et de validation d données
je lui donne aussi pour chaque champs du formulaire le type de donnée et la façon don la vue me les donnes (une date peut être un entier, une chaîne ou plusieurs entier)
je n'écrit aucune ligne de code pour mon contrôleur
et pourtant il fonctionne il valide et filtre correctement les données et m'affiche correctement les messages d'erreurs
cela est possible parce que chacun s'occupe que de sa partie.
je n'écrit plus de procédure de filtrage je ne fais que déclarer celle dont j'ai besoin.
par contre mon métier lui je ne peux pas le généraliser la règle de mon métier lui est propre. par contre valider une donner quelque soit la règle c'est toujours la même chose et l'API pour le faire est toujours la même
je peux donc définir une interface et il suffit que le modèle implémente cette interface pour que je puisse généraliser mon contrôleur
Sans cette séparation claire impossible d'en arriver là
A+JYT
Je t'avoue que j'ai du mal à te suivre sur ce coup là. Pourrais-tu schématiser cette solution en UML ?..
bye
j'ai d'un côte ma vue
de l'autre mon modèle
le modèle implémente une interface de validation de données
mon contrôleur est toujours le même à des détail près
rechercher
afficher une liste
préparer un formulaire pour ajout
préparer un formulaire pour edition
afficher un formulaire
vérifier
enregistrer
j'ai donc une classe abstraite qui implémente tout ça
pour faire mon contrôleur je dérive cette classe et je lui dis comment assurer la liaison entre la vue et le modèle.
j'ai besoin pour ça de lui dire comment sont représenté les données des deux côté.
par exemple si mon modèle utilise un objet à trois champs pour représenter les dates et que ma vue elle utilise une chaîne de caractère
j'indique à mon contrôleur que pour le champs date il recevra de la vue une chaine q'il lui faudra donc utiliser le filtre DateString (éventuellement en fonction de la langue) que lorsque il aura une valeur acceptable il devra en faire une date sous forme d'objet pour le donner au modèle. qui la validera.
dans l'autre sens lorsque le modèle fournira une date elle seras transmise à la vue sous forme d'une chaîne formatée (en fonction de la langue)
je ne fais donc que du descriptif sur mes données
je ne m'occupe pas de ce qu'elle signifie ni de comment elle sont présenté
je ne m'occupe que d décrire ce qu'elle sont.
tout le reste est hérité de la classe abstraite.
ainsi lorsque je reçois des données du formulaire je les filtre en fonction de la description et j'obtiens des donnée compréhensible par le modèle (ou des code d'erreurs) il ne reste qu'à demander au modèle de valider les données.
pour passer à l'étape suivante.
c'est donc un comportement totalement générique que j'ai mis dans une classe abstraite. je n'ai donc rien à écrire pour la vérification de mon formulaire dans mon contrôleur.
il en va ainsi de toutes les actions du contrôleur vu que son seul job c'est de gérer les enchaînements d'action qui sont toujours les mêmes dans un crud
et de s'assurer l'échange de donnée entre le modèle et la vue. et pour ça il à juste besoin d'une description de cet échange
le champ vitesse du formulaire qui doit contenir un entier correspond au champs velocity du modèle qui est un float.
on voit bien qu'avec juste cette information on peut écrire un code générique qui assure l'échange. parsing du champs text du formulaire pour en extraire un entier et conversion en Float pour le donner au modèle. de même formatage du float du modèle pour donner une chaîne contenant un entier pour le donner à la vue.
donc mon crud est totalement générique pas de ligne de code à écrire pour qu'il fonctionne. juste du descriptif.
Voilà.
A+JYT
Merci pour ces précisions. Je commence enfin à comprendre ton raisonnement
Je vais mettre tout ça à plat et comparer...
bye
Bonjour, j'ai parcouru ce post qui est vraiment intéressant.
J'aimerais avoir un petite précision sur les filtres et l'échappement des données dans la vue.
Sur la doc officielle du ZF ont peut lire :
Dans la vue, doit on échapper les champs retourner par un objet Zend_Filter_Input ?37.3.1. Echapper la sortie
Une des tâches les plus importantes à effectuer dans un script de vue est de s'assurer que la sortie est correctement échappé ; de plus ceci permet d'éviter les attaques de type cross-site scripting (XSS). A moins que vous n'utilisiez une fonction, une méthode , ou une aide qui gère l'échappement, vous devriez toujours échapper les variables lors de l'affichage.
Dans mon formulaire si je rentre un "é" et que je le soumet à un filtre. lorsque j'utilise $this->escape($this->dataForm->nom) j'obtiens un "é" sans échapper j'ai bien le "é". Mais dans se cas est ce que mon formulaire est sécurisé ?
Bonjour,
Par défaut, lorsque tu récupères des données passées dans Zend_Filter_Input, elles sont échapées avec le filtre Zend_Filter_HtmlEntities (qui utilise la fonction interne htmlentities).
En pratique, il y a seulement certains caractères qui sont dangereux et qui doivent toujours êtres échappés, il sont listés dans la doc de la fonction interne htmlspecialchar(). Lorsque tu échappes tes données dans une vue (avec Zend_View::espace()), c'est cette fonction qui est appelée par défaut.
Par ailleurs, si tu utilises les View Helpers (FormInput, FormSelect, etc...) pour créer des éléments de formulaires, les valeurs utilisées seront également échapées avec le filtre spécifié par défaut dans Zend_View, attention donc à ne pas échapper deux fois les mêmes valeurs.
bye
Merci pour ta réponse, donc j'échappai 2 fois la même valeur...
Répondre avec citation
Partager