The question is quite clear and I'm going to explain my point of view.
If you take a look at Struts or JSF,and I'm sure, for a lots of others frameworks out there, the form verification are made in the View side.
For example, this is a wrong method (IMHO) used by JSF templates :
<%@taglib uri="http://java.sun.com/jsf/core" prefix="f" %>
<%@taglib uri="http://java.sun.com/jsf/html" prefix="h" %>
<f:view>
<h:form>
<h:outputText value="Name: "/>
<h:inputText id="name" required="true" maxlength="20" value="#{user.name}">
<f:validateLength minimum="3" maximum="20"/>
</h:inputText>
<h:message for="name" style="color: red"/>
<h:commandButton value="Submit" action="success"/>
<h:form>
</f:view>
The point I want to raise is the fact that it's generally the job of the web designer to make the template, the forms, but NOT to make the verifications !
Yes he need to know which value is needed, eventually which type is waited (for implementing nice date picker for example), but not to test if the string is too short or too long, if it's an email, etc.
The side that must handle this kind of operation must be the Controller, that know which type a field must be. Eventually, the Model side can impose its structure to the controller, but never the View side ! A webdesigner must never impose the structure of the data. Right ?
Ok now everyone is boiling about what javascript is able to, and I totally agree with that, but with restrictions.
Client-side verifications must be implemented only to improve user experience. Never forget that javascript can be disabled !
But it's a great idea to tell at your webdesigner the constraints for the form in the fact that he could implement a client-side verification, and then, your controller will do the server-side (final) verification, in case javascript is disabled, or some bad guy try to play with your code :p
I would be pleased to know your opinion about that :)
13 Comments so far ...
Neige says:
In the end, i'm not sure i understand your point of view : do you think the form validation must be in the controller, and therefore, that the example you give of a JSF template does not conform to your opinion ?
Personnally, i think that, true enough, the validation should not be in the view...
P.S. : maybe i'm not used to reading technical articles in english when i'm used to reading their authors in french ^^
Cyril N. says:
Yes, I think the form validation must be in the controller. The JSF template is just an example of what I think it's wrong :)
Neige says:
So we're ok... I was really wondering if it could be a good thing to let the designer decide of constraints on form fields in the view...
In my last job I had to develop a system to let commercial service create surveys. I used an xml file to store the steps and questions, and let the creator (not a developper, but a commercial agent) define what type of data could be given in the answer, what length, ...
But it was a very specific case : the creator wanted to fix strictly what type of data he wanted to get to manipulate it.
TR!K says:
Pour ma part, je pense que dans le cas d'un application web, le contrôle des données doit être fait dans la vue à l'aide de code javascript pour avoir une meilleure interaction avec l'utilisateur final, mais aussi, et surtout dans le contrôleur avec des méthodes adaptées. J'irais même jusqu'à utiliser des méthodes particulières dans ma DAO pour délivrer un niveau de sécurité supplémentaire.
PS : Désolé mais je ne suis pas tres bon en anglais :/
Cyril N. says:
@TR!K : Je serai intéressé que tu détaille ta pensée. D'après ce que j'ai compris, tu pense que le contrôle devrait être fait côté utilisateur ? Imagine si le javascript est désactivé, comment tu fait ? (ou si l'utilisateur utilise l'extension noscript de firefox). Mettre des méthodes dans ta DAO pour ajouter un niveau de sécurité pourrait apporter plus de problèmes qu'il n'en résout. A mon avis (c'est le but de cet article en même temps ;)), le controlleur voit son rôle parfaitement mis en évidence dans le cas d'un traitement des données tel que la soumission de formulaire.
C'est pas grave pour l'anglais, je suis pas renfermé aux langues :p Juste que je ne risque pas de répondre si c'est en espagnol, allemand, etc :p
TR!K says:
Après une bonne nuit de sommeil, je vais tenter de m'exprimer plus clairement :)
Je pense que des points de contrôles doivent être mis en place dans la vue, le contrôleur et le modèle.
De ce fait, profiter dans la vue de l'interaction instantanée avec l'utilisateur qu'offre le js pour guider sa saisie, générer des erreurs bloquantes dans le contrôleur en fonction du type de donnée attendu, et éviter l'injection sql et le xss dans le modèle.
Cyril N. says:
Dans ce cas je suis d'accord avec toi, mais l'ordre de priorité à son importance. Le Controller est maître, c'est à lui de s'occuper des vérifications. Le Modèle n'aura que pour action d'insérer les données (dans ce cas). Si une donnée ne correspond pas, elle sera formatée (si tu lui passe un float dans un champ INT, tu perdra les virgules. Si tu lui passe un string dans un champ date, tu aura des 0, etc).
Enfin, la vue ne s'occupera que de rendre l'expérience utilisateur plus agréable (éviter le rafraîchissement de la page, lui dire si son pseudo est disponible, etc)
TR!K says:
Concernant la vue, c'est exactement ce que je pense :)
Pour le contrôler, je pense qu'il doit faire 2 types de contrôles : le formalisme des données(metier) et la sécurité de l'application.
En cas de non conformité, une erreur ou une conversion devra être générée.
Le modèle (plus particulièrement la DAO), devra simplement inclure des méthodes d'insertion avec un minimum de contrôle pour la sécurité et non pour le formalisme selon moi.
De toute façon, le sgbd sera capable de générer des erreurs contrôlées en cas de pb selon le formalisme des tables également.
Au final, je crois que nous sommes globalement d accord surtout concernant l'illusion de sécurité apportée par le JS dans la vue.
Ensuite il est évident que le contrôleur devra se charger de la vérification des données pour le formalisme, mais aussi pour la sécurité.
Seulement, je pense simplement que l'on peut aussi intégrer certaines pratiques supplémentaires dans le modèle au travers de la DAO pour la sécurité avant tout.
Dans tous les cas, je suis ravi de pouvoir partager sur ce sujet :D
Cyril N. says:
Le plaisir est partagé :)
Ajouter une couche de sécurité dans le dao, je ne pense pas. Même si ce serait plus sûr (éviter le xss ou le sql injection comme tu l'as dit avant). Si tu regarde doctrine ou propel ne possèdent pas de technique pour controller les entrées, car ce travail doit se faire du côté du controlleur. C'est une mode de pensée à enseigner au développeur, et si l'application à des problèmes de ce type, ce n'est pas le modèle qu'il faut inculper.
TR!K says:
Tu as raison. Le modele ne doit en aucun cas être pointé du doigt à cause de ce type de problématique.
Quand je parle de couche de sécurité dans la dao, je pense simplement à des méthodes de traitements classiques qui par nature intégreront une éventuelle sécurité.
Disons que j'ai tendance à porter une ceinture et des bretelles :)
Ca doit être mon coté sentimental pour certaines technos intéressantes avec pdo qui évitent l'injection sql, qui me pousse à insister sur ce genre de discours :D
En plus, comme je suis admin réseau de formation, mon enseignement en tant que dev web est toujours en cours ^^
Neige says:
Concernant la vérification des données dans un formulaire avec JS, on est d'accord, c'est surtout du confort, pas ce sur quoi doit se reposer le dév.
Par contre, dire que c'est dans la vue, à mon avis, ça se discute. S'il est vrai que le JS fait partie intégrante de la vue, les champs à vérifier et leur nature peuvent (doivent) être décidés dans le contrôleur ou le modèle.
Je m'explique. Imaginons qu'on génère un formulaire dont on souhaite vérifier la validité des données d'après un schéma précis (tel champ alphanumérique, tel autre numérique avec des valeurs de x à y, encore un autre champ avec des données alpha respectant un masque déterminée, etc). JS va effectivement vérifier la validité des données, mais ce n'est pas JS qui va établir le schéma à respecter : c'est le contrôleur, en fournissant à JS les données nécessaires pour effectuer les vérifications.
Je sais pas si ça apporte quelque chose, je suis pas encore bien réveillé...
TR!K says:
C'est effectivement parce que le js agit directement dans la vue.
Tu as raison de préciser que c'est le contrôleur qui devra faire office de relais pour établir le schéma.
En gros ce qu'il faut retenir, c'est qu'il faut se méfier des faux amis comme le js et se focaliser davantage sur les choses que l'on maitrise comme le contrôleur.
Moi je ne serais pas bien réveillé toute le journée : / ma fille se lève tous les jours à 7h même le samedi et le dimanche #_^
Je vais d'ailleurs de ce pas faire de la peinture avec les mains \o/
Cyril N. says:
Lol :)
On est bien d'accord, la vue, avec le js, n'est là que pour améliorer le confort utilisateur, pas pour faire des contrôles décisifs.