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 :)
