On Nov 4, 2008, at 1:00 PM, Karen Tracey wrote: > [...snip...] > The order of things during validation is specified clearly in the > docs: > > http://docs.djangoproject.com/en/dev/ref/forms/validation/
This was useful, thanks. > > > This page has a subsection on cleaning fields that depend on each > other, where it is recommended that such validation be done in the > form clean() method as opposed to an individual field's clean > method. An individual field's clean method should really focus on > validating that field's data, not that field's data plus some other > field's data. It isn't clear to me if you are unaware of the > existence of the form's overall clean() method or if you just don't > agree with the recommendation that that is where cross-field > validation should be performed. (Also cross-field validation didn't > seem to be an issue in your first message so I don't know if we've > gotten off on a tangent or if that was really an issue in your first > example.) I may have been aware of it. I think I've seen e.g. password2 validation in a couple of places though and just assumed... Well, sort of a tangent. What I was getting at is that the "raw" data of the form (i.e. the data from all field.clean() calls) should, in my mind, be set up before creator validation is called. That's probably a little specious in the face of form.clean() though. > > > > Second this tends to make righting unit tests rather more error > prone. Or at least the sort of tests I'm used to writing. I realize > there are various idiomatic ways of dealing with the problems I'm > having (spelunk the error list, etc) but certainly I can imagine > better ways. Keep in mind I'm not at all a python person (yet) so > this may in fact be entirely infeasible. But presumably one can do > something like declare clean_xxx as follows: > > def clean_something(self, password1, password2): > # Stuff > > Provided one can get to the names of the arguments it seems then > that it would be useful to do something in full_clean() like > > for each argument in the args list of each clean_xxx method: > name = arg name > if there_is_a_field_named(name): > set the value of that argument to field.clean() > else: > raise somethingorother > > I like this in several dimensions, much as I'd like faster-than- > light travel, which is to say it would be really cool but I don't > see how to get there from here. > > Regardless of whether this is implementable in Python I feel it > would be rather more complicated to explain and use than the current > approach. clean for a field not only validates that the data is OK > but normalizes it to a consistent form -- if you start trying to do > cross-field validation before all of the individual data bits have > been normalized then your cross-field validation has to worry about > handling non-normalized data. As it is if you put your cross-field > validation in the form's clean() method then it only has to deal > with validating normalized data. This is a win, I agree. > > > > Anyway, I can see several ways around this and I'll pick one or the > other. OTOH, if testing at this level of granularity is inconsistent > with the python/djano world view, I would love to hear what's > better. Understanding code is easy(ish), philosophy is hard. > > Testing that an individual field's validation works as expected is > not inconsistent with Django or Python philosophy. However testing > that by calling the field's clean method directly is not the right > approach -- this method is intended to be called by Django as part > of the overall form cleaning. Therefore to ensure that the > environment/args/etc is set up for it as it will be when your code > actually runs in production, it is best to test it by calling the > form's is_valid() function, and examining the results in the effect > it has on the form. That's what I got too as well. Thanks for the time and patience, ---Rick > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
