[GSoC] model validation
Honza Král
last week I was busy during EuroDjangoCon, so I am afraid there was
close to no progress on actual work. I did however give a talk on the
topic (see slides at [0]) and got into a few interesting discussions.
As a result of the latter I would like to reopen one design decision
that was made during DjangoCon - the signature of validators. I will
present three options and ask for your votes, if you only wish to
vote, feel free to respond to me personally to avoid flooding the
list. Feel free however to make any comments you wish.
Option one "simplistic":
def is_integer(value):
try: int(value)
except ValueError: raise ValidationError()
+ very easy, testable, not dependent on django at all
- unable to validate across fields
Option two "compromise"
def is_integer(value, all_values):
try: int(value)
except ValueError: raise ValidationError()
also allows for more complex validation across multiple fields:
class MatchesOtherField(object):
def __init__(self, field): self.field = field
def __call__(self, value, all_values):
if all_values[self.field] != value: raise ValidationError()
+ can work across fields with class based design for easy generation
- can't access methods on models
- models will have to be translated to dictionaries
Option three "maximalistic"
def is_integer(value, all_values={}, model_instance=None):
...
form passes in dictionary of cleaned_data, model passes in 'self'
+ can validate across many fields, even use methods on models
- requires tiny wrappers to get to the data (either from all_values or
the instance)
Each solution has it's advantages, the questions on which decision
should be made are:
1) What is a typical use case for validator (single value/across
fields/model aware)?
2) Which validators in each category can be sanely reused and which
would get so complex that it would be easier just to write utility
functions and assemble the logic by hand in .clean() methods?
3) Do you really want to access model methods in validators (why
wouldn't it itself be a method on the model then)?
4) How many people will actually write their own validators?
By next week I should have the answer to these questions (at least my
guesses if too few people participate) and will try and modify the
patch to reflect the choices made based on those answers.
0 - http://honzakral.com/validation.pdf
Honza Král
E-Mail: Honza...@gmail.com
Phone: +420 606 678585
hcarvalhoalves
> Phone: +420 606 678585
Thanks for raising attention on this feature, I wasn't aware of your
"Model Validation" branch and GSOC project.
One question: I'm afraid of the implications of coupling validation to
models instead of the actual solution (Form/ModelForm). Coupling it to
models means we have one single point for validation, but data comes
from all sort of forms and data sources, and it's not a "one size fits
all" case.
I find myself defining different validation rules, on a per-form
basis. One use case for this is when I use different forms for
displaying on a view or only for capturing POST data and validating
it. Also, it applies to your "validate across fields" case, because
often I need to validate if at least one of two non-required fields
are present, or validate one field according to another field value.
So I'm afraid if this move can actually make validation easier,
without flooding validation logic inside views, or making it too
difficult for rules that validate against more than one field,
compared to the actual Form solution (where I can encapsulate each
different validation logic on its own class).
Michael Radziej
> Thanks for raising attention on this feature, I wasn't aware of your
> "Model Validation" branch and GSOC project.
>
> One question: I'm afraid of the implications of coupling validation to
> models instead of the actual solution (Form/ModelForm). Coupling it to
> models means we have one single point for validation, but data comes
> from all sort of forms and data sources, and it's not a "one size fits
> all" case.
Ah, you come a bit late to the party. The idea is not to replace form
validation, but to have an additional layer at the model for the stuff that
is sensibly handled at the model. There's probably a good description on the
Django wiki.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689