[Dbix-class] DBIx::Class, another data validation approach

[Ulrich Kautz]

Rob Kinyon schrieb:
> On Tue, Jul 21, 2009 at 09:41, Ulrich Kautz<uk.lists at fortrabbit.de> wrote:
>   
>> Hello all
>>
>> sometime ago i wrote a data validation module for validation right in
>> the model. I didnt published it yet, and now i searched the list and
>> found DBIx::Class::Validation.
>>
>> However, i thought about using this one instead, but the migration would
>> be to extensive for me and i think it does not fit my needs.. Hope this
>> isnt too confusing; in the attachment is my idea of validation
>> (DBIx::Class::DataValidator).
>>
>> Any tests, critics and ideas are welcome. I would upload it to CPAN as
>> soon as is find time to clean the docs and write some more tests (the
>> included should work).
>>     
>
> Instead of dropping a blob of code, why don't you put together a
> description of what yours does that DBIC::Validation doesn't? Maybe a
> pros and cons for each module. If you want someone to use something
> other than the established standard, you have to make the case. You
> might well be right that yours is better for certain situations, but
> I'm not going to take the effort to figure that out - that's your job.
> :)
>
> Rob
>   
Actually, i didnt want to make a competition out of this, i just though
it might come in handy for someone with the same requirements as i have.
But you are right, i should mention at least why DBIx::Class::Validation
is not sufficient for me.

These pros and cons are from my perspective. Eg you can surely achieve
inheritance with DBIx::Class::Validation within certain circumstances
via outsourcing your validator profiles in external modules and merge
them back in the model.. but on profile level, this is far to imprecise
for _my_ purpose. And in opposite, you can argument that inheritance on
model level is not a good approach for your kind of application, and so
on ..


DBIx::Class::Validation

PRO:
+ Very simple to use, a single module, no complex configuration (besides
the validation profiles)..
+ Supports multiple validation modules (besides FormData::Validator)

CONTRA:
- Very "static", only one validation context (aka one filter profile)
for each model is possible (or validation becomes again part of another
layer, where you provide the profile definition)
- Half way solution, columns and validation definition still separated
- DRY philosophy not achieved, because inheritance of validation not given
- No deflate / inflate awareness


DBIx::Class::DataValidator

PRO:
+ Multiple mergable validators supported for multiple contexts at
runtime (create, update, customs.. )
+ Brings columns and validation together at definition time.
+ Better DRY support via named validation methods and column classes
(inheritable)
+ Deflate / inflate aware

CONTRA:
- More complex usage, consists of two modules (ResultSet and Component),
more settings (configuration) makes it less lighweight
- Bound to Data::FormValidator



Ulrich