[Catalyst] Where should constraints go

Dami Laurent (PJ) laurent.dami at justice.ge.ch
Mon Nov 6 07:13:41 GMT 2006


> De : Ian Docherty [mailto:ian at iandocherty.com] 
> Envoyé : vendredi, 3. novembre 2006 15:40

> Where should the various constraint values go in my MVC 
> structure? For example the Model defines the size of each 
> field in (for example) a username field in the User database 
> table as being 16 characters max.
> 
> ...
> 
> I cannot think of a 'clean' way of getting these database 
> constraints from the Model into the View.
> 
> Anybody else tackled this issue?
> 


Hi Ian,

I am currently looking at this issue for a big intranet application where we have many business rules to validate. As you say, rules interfere both with models and views,
and it would be nice to avoid duplicating the information. 

Now where should rules live ? Deriving rules from the database, as Carl suggested in this thread, is an excellent start, but it is not enough : there might be many things that a database cannot express, like regular expressions, contextual dependencies, or your example of date boundaries depending on the current date. On the other hand, form validation packages are often too much focused on the view and also fail to express the complex rules just mentioned. 

The general problem is that the range of possible rules is very wide : some rules are quite simple, and for those we would like a short declarative language to express them, while other rules definitely need some computing power that goes beyond a declarative language.

So I tried to address this in Data::Domain, which was published on CPAN just 2 weeks ago. This module is designed for providing a compact way to express complex constraints about structured data (including lazy constraints that may inspect the surrounding context). It then generates a structured set of error messages that can be fed to the view, either server-side through Template Toolkit, or client-side through Ajax methods. Messages are either auto-generated or can be redefined by client code (for example for internalization). The general scenario is that you get structured data by piping the parameters of your HTML form through CGI::Expand; then you validate the whole tree, and get back a tree of error messages that can be mapped back to the form fields.

You may also want to have a look at Declare::Constraints::Simple, which addresses the same problem and has some similarities in design.

Best regards, L. Dami



More information about the Catalyst mailing list