On Jan 19, 1:43 pm, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > one. Short version: when the form field validation would match what the > model field is going to do anyway, don't do anything at the form level. > The model field validation is about to be called anyway.
[snip] > The solution here might not be too difficult and doesn't need the > requirement of communication from the form to the model about what it's > already done. > > To wit, when a formfield is constructed automatically from the model > field, if the default formfield doesn't do any validation/normalisation > beyond what the normal model field does, the formfield() method on the > Field subclass returns a formfield with no validators. Thus, when the > form cleaning process is run, all the validation for that field is done > by the model. Thus form fields returned for model fields could well be > slightly modified (in that their validator list is different) from what > you get directly from using forms.fields.*. > > That dovetails nicely with the reuqirements of custom form fields. When > a custom form field is created, the form field validation won't be > skipped (unless the creator wants to remove any validation from the form > field), so any differences between the default model field validation > and the custom form field validation aren't overlooked: they both get > run (which is the correct behaviour). Looks like a good action plan. > Attempts to abstract away similar-but-not-the-same algorithms can often > lead to more difficult code than writing the same thing out directly in > the two places. It tends to show up in the number of parameters you pass > into the abstract algorithm and/or the complexity of the return types. > And, in this case, it's only two places, not fourteen or anything like > that. So whether this is worth it tends to be implementation specific. Yeah, I won't pursue this further, although I still think the result would be cleaner, not uglier. > As a style issue, there's a bit of an arbitrary split going on there. > Type conversion is really part of what we're calling "validation" (since > the type coercion is part of the normalisation part of the process, > which we tend to lump into validation). I'd lump things a bit closer > together in the source. There's not really an external use-case scenario > for the converters and, even within Django, they don't have a lot of > user outside of the validators (we can't do a lot of sharing with the > database-specific backend converters, since they do tend to be > backend-specific). > > Maybe (and looking at my notes, I might upgrade that to probably, given > the number of times I've mentioned it), we need to make a directory for > django.core.validators instead of a single file. That gives us room to > split out converters from things that work with standard types. But > definitely try to keep them close together in the source, rather than > putting them in django.utils, which can sometimes be a dumping ground > for stuff that better belongs elsewhere. As seen in the commit, http://github.com/mrts/honza-django/commit/a8239b063591acc367add0a01785181a91a37971 , my initial quick solution was to lump them into the validation module (as there's lot's of intermingling between validators and coercers, exemplified by merging to_pyton() and validate() to clean() in forms). The directory-based approach is best, I'll go with it -- but it's yet uncertain when as I have to handle pressing matters at work during daytime. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
