On Mon, 2007-08-13 at 23:51 -0500, Gary Wilson wrote:
> Malcolm Tredinnick wrote:
> > On Mon, 2007-08-13 at 18:00 -0700, sime wrote:
> >> 1. Magic cleaned_data - So we can get/set values out of order and
> >> before the clean() run, having themselves clean implicitly as
> >> required.
> >
> > Can you give an example of what you mean here? I can't visualise what's
> > going on.
>
> I assume what is meant is that when accessing a key in cleaned_data for
> a field that hasn't been cleaned yet would trigger cleaning of that field.
>
> So with:
>
> class MyForm(Form):
> initial = CharField()
> name = CharField()
>
> def clean_first_initial(self):
> initial = self.cleaned_data['initial']
> name = self.cleaned_data['name']
> if name and not name.startswith(initial):
> raise ValidationError('Initial must match first letter')
>
> the accessing of self.cleaned_data['name'] would go clean the name
> since, at this point, it hasn't been cleaned yet.
>
> Behind the scenes, we could track what fields have been cleaned and set
> that cleaned bit for the field when cleaning begins, but there would be
> a decision to make about what to do when a circular dependency is
> encountered.
>
> I'm not sure this extra logic would be worth adding, but the thing I do
> like about it is that field cleaning would not be sensitive to the order
> in which the fields are defined in the form.
It's multi-field cleaning. Call it from your form's clean method. For
the relatively rare cases when this is needed, I don't think it's worth
extra logic, you're right. It looks like standard multi-field stuff and
we have a spot for that.
>
> At the very least though, I think we could break up
> BaseForm.full_clean() so that we have a method that does cleaning of one
> specific field separate from the method that cleans the form. This
> would make more exotic form handling easier by allowing the author to
> just override the form-level clean function, calling the field-specific
> clean method at will.
Maybe. Getting the API right for that might take some thinking. I'm
wondering if you always pull the data for specific field cleaning from
field.widget, as now, or if these exotic cases of which you speak are
going to supply the data some other way. In other words, have a think
about which part you really want to factor out.
On a somewhat related motivation note: my inclination is usually against
splitting things up into arbitrary extra functions because it can make
tracking the flow of information that much harder (you end up jumping
around between functions all the time), rather than just reading
linearly. So I'm not leaping to, say, split it into two layers of
function calls there (the loop and then each field). Not saying that's
an argument against here, but if it ever sounds like I'm taking the
"prove it, first" side of these design debates, it's possibly partly
because of that. Function calls aren't free and reading from top to
bottom of the screen, one line to the next, is easiest to maintain. It's
only item #57 on a list of 58 things to consider, but it's on the list.
>
> And speaking of breaking up BaseForm methods, _html_output is one beast
> of a method that should be broken up in the same way as above, where
> there is a separate method for outputting an individual field. Someone
> help me, is there a ticket out on this already? I vaguely remember one...
Woah ... deja vu. I started doing that when I was reviewing #4752 on the
weekend. I'm still futzing around a bit with what might be a useful
split, but single field rendering (with it's associated error) looks
like it might be useful to pull out. Still thinking about the design a
bit there.
Malcolm
--
I don't have a solution, but I admire your problem.
http://www.pointy-stick.com/blog/
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
