Philosophical Question: validation of input data

Question

This is a "best practices" sort of question...
I came across this statement while going through the latest Tutorial (the tutorial is great, by the way): "The page author registers the validator on a component by nesting the validator's tag within the component's tag."
It strikes me that field validation should be the responsibility of the model developers rather then the page authors. Intermixing validation logic with presentation logic seems like a violation of the spirit of the desire to separate the model from the view.
Validation of a form's fields should be associated with the model rather then with the presentation. There may different presentations for the same model, and the validation rules should (more then likely) be consistent regardless of the presentation.
Am I missing something?

Answer 1

I've used Struts for years (and am very grateful), but
I've always been bothered by the manual
synchronization necessary between the XML, the Java,
and the JSP. In the horrible bad old days of
generating HTML from a servlet the compiler would
catch dumb mistakes. Now we have to wait for run time
errors. This worries me.It worries me, too. One of the arguments for using systems languages (like Java) to do web development, instead of scripting approaches (like ASP), is the compile-time error detection available in Java due to language features like strong type checking, etc. In ASP, you had to wait until runtime to find out you had typed a function name incorrectly, etc.
Well, Microsoft has finally delivered ASP.NET, with strong type-checking in languages like C# and VB.NET. I've experimented with it quite a bit, and they really have worked hard on giving good diagnostic messages, and on catching things like naming discrepancies between components defined in the HTML (.aspx) and the corresponding C# source code (.aspx.cs) at page compile time.
Meanwhile, the Java community seems to be moving in the opposite direction, introducing features like the JSTL (with its runtime Java introspection). Frameworks such as Struts and the new JavaServer Faces rely heavily on JSTL to avoid having to put Java expression scriptlets in the page, but you give up the compile-time type checking. Also, errors caused by naming differences between beans referenced both in .jsp files and in .java files are often hard to track down, because all you may get is a null pointer diagnostic or an empty value.
I do think tools support will help with some of the XML - Java - JSP synchronization issues, when the vendors catch up, but the whole idea of splitting up an application into declarative (XML / JSP) and procedural (Java) sections tends to make for higher learning curves, and complicates debugging.
I earnestly hope that, as we approach the final stages of the JSF reviews, much thought will be given to "making easy things easy". If this initiative is Sun's answer to Microsoft's ASP.NET, which it appears to be, the goal has to be to make Java web application programming accessible to the average developer, as well as making good developers more productive. Early error detection certainly belongs in there somewhere.
Stephen