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
_______________________________________________
List: Catalyst@lists.rawmode.org
Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.rawmode.org/
Dev site: http://dev.catalyst.perl.org/
