On May 12, 9:28 pm, Honza Král <[email protected]> wrote: > Hi, > 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: [email protected] > 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). --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
