[Catalyst] State of the art in form validation; opinion poll. Model based forms/validation?

[Dami Laurent (PJ)]

>-----Message d'origine-----
>De : Ashley Pond V [mailto:apv at sedition.com] 
>Envoyé : mercredi, 5. décembre 2007 02:47
>À : The elegant MVC web framework
>Objet : [Catalyst] State of the art in form validation; 
>opinion poll... Model based forms/validation?
>
>I'm playing with CP::FormValidator::Simple and I like it all right  
>but I feel like there must be something better than it and  
>CP::FormValidator.
>
[snip]
>I'm leaning more and more to having *all* of this stuff defined  
>(validation patterns, user messages for invalid input, clues for CGI  
>fields) in the Model (DBIC; I love it and never find time to try  
>Rose). Sort of a super phat Model. If it's not defined exclusively  
>there, it ends up defined there (via schema), the controller,  
>possibly the templates (messages), and even client-side in JS. I know  
>I'm showing my tremendous grasp of the obvious when I say, this is  
>just effing awful.
>
>What are best practices? DBIx::Class::Validation reusing your form  
>package profiles? But you still have to write your own forms. I've  
>searched around a lot and can't find a thorough, coherent Catalyst  
>related doc about it.
>
>I really want one, final approach to this I'll use every time from  
>now on instead of experimenting with packages and home rolled stuff  
>over and over. If someone is there, or even close. Please kick down.
>
>As always, I appreciate everyone's time and expertise.
>
>Thanks!
>-Ashley
>

Hi Ashley,

We are building a big application for State of Geneva, and here is what we do :

- assemble HTML forms using plain Template Toolkit. Initial values are all empty. Field names use a dot notation à la CGI::Expand.

- initial data is passed as a JSON tree, and some javascript code on the client-side fills the form from that tree. Users can also save the tree locally and reload it into the form later.

- upon submit, the form data is sent through Ajax. The server pipes that data into CGI::Expand, and then into Data::Domain. If the data is OK, it performs the action; otherwise it returns a JSON tree of error messages. Javascript code on the client-side navigates through these messages and puts the focus on appropriate fields.

So all business rules and error messages are described in Data::Domain. The actual data storage is maintained independently by the DBA, directly within the database. Inbetween sits DBIx::DataModel, a thin ORM that deals mostly with associations through primary and foreign keys, but knows very little about other columns (data just passes through). 

So in contrast with some other approaches, here the data description is not centralized : if you add a new field, you have to act on the database, on the Data::Domain validation rules, and on the Template displaying the form. For quick scaffolding of an application, this would definitely be slower, but in the long run it pays off, because each component does just what it knows best to do : storing the data, presenting the data, validating the data. And you can have different people with different skills maintaining these 3 sides.

This approach was presented at YAPC::EU::07; you can grab the slides at http://laurent.dami.free.fr/slides/YAPC07/

Enjoy,

   Laurent Dami