On Tue, Nov 4, 2008 at 2:06 PM, Rick Kitts <[EMAIL PROTECTED]> wrote:
> Well, I think it's clear what I see. I sort of disagree about the impl, > design, call it what you will. > It wasn't clear to me what you had seen nor what you wanted to argue about though you have clarified that some in this post. > > Specifically, the current impl makes testing harder than it needs to be, or > at least the testing that I'd like to do. That is, I have a field, that > field has validation rules and I'd like to test that the work. Strictly a > field has 2 sets of validation rules, those on the field itself (or is it > more correct to say on the widget), and a (possibly empty) set of rules > defined by the form creator (call them creator validations). > > So a couple of issues about this. > > First, the cleaned_data attribute (member?) is not guaranteed to be > populated fully at the time any creator validation is called. That is, if I > have 2 dependent fields, say password1, password2, I cannot get > cleaned_data['password2'] inside of the creator validator clean_password1() > unless/until the full_clean() impl get's to the field password2. Thus the > ordering of fields and the impls of clean_xxx() are coupled in what I'd call > a non-obvious fashion. This seems unnecessary but that's just me. > The order of things during validation is specified clearly in the docs: http://docs.djangoproject.com/en/dev/ref/forms/validation/ 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.) > > 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. > 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. Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
