[Catalyst] Form validation in insert() and update()?

mla maurice.aubrey at gmail.com
Thu May 17 02:46:57 GMT 2007


Jason Gottshall wrote:
> This gets at precisely the issue I've been wrestling with lately.
> Validation constraints at all levels (db, model, controller, form, etc.)
> seem to sort themselves into two general categories: field-specific
> questions ("Is it required/unique?", "Does it match a given pattern?",
> etc.) and broader domain-level interdependencies ("Require at least one
> of the following...", "If A is 'foo' then B must match /^bar|baz|qux$/",
> etc.) This leads me to want to define those constraints in different
> places. 
> 
> For example, I'd love to be able to define per-column validation
> patterns/subs at the DBIC level as Chris describes above, and then
> utilize that meta info to validate input at higher levels (model,
> controller, form) as MST described in another post on this thread. But
> I'd also need a way to create a profile for, let's say, form field
> validation interdependencies (which can be independent of
> domain/model/db-level interdependencies, as previously noted). But how
> do I implement a concise way of accomplishing all these things?
> 
> Or is the fact that I have so many things to worry about an indicator
> that this isn't going to be concise?
> 
> If Chris were to implement a per-column profile option for
> DBIx::Class::Validation, I'd be inclined to look for a way to use
> Data::FormValidator at several levels. Would it make sense to have a
> method that would compile everything from %colinfo and
> validation_profile() into a single profile that could then be utilized
> (and modified/extended) at the model/controller level?
> 
> And should this branch of the thread be moved to the DBIC list?

I'm thinking Catalyst::Model should provide some sort of interface for
this.

 From what I understand, Catalyst::Model::DBIC::Schema is a wrapper class
that provides the "model interface" for DBIx::Class objects. Having that
interface is important so the framework as a whole has a consistent API
to the models.

But Catalyst isn't tightly coupled to DBIx::Class. I can design the
model however I want, with whatever data store I like, and as long as it
exposes that common model interface, I can plug it into Catalyst.

In the common case, I want models with attributes, accessors/mutators,
constraints, and the ability to load/save instances.

If there was a consistent interface to the model that provided those
functions then a lot of the standard data validation and CRUD stuff
becomes dead single.

Any generic model that wanted to be pluggable into Catalyst could
provide that "attribute" interface (other models would still work,
just not with anything that assumed the attribute interface was
present), either directly or as a wrapper class.

We'd still want the validation module to be independent of Catalyst,
of course... but having the ability to automatically
interrogate and manage a model like seems very powerful.

Maurice



More information about the Catalyst mailing list