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.
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.
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...
>> 4. Pass value to field clean_ method as parameter - Eg
>> clean_field(self, value) - why bother users with the extra line of
>> code? Obviously they are going to want the value, aren't they?
>
> It's been discussed before why we haven't made this change. Bringing it
> up again without at least addressing the previous arguments against
> isn't going to work. It hasn't been considered worthy of the backwards
> incompatible breakage, although I'm not putting serious money on that
> not changing.
I don't think the backwards incompatibility argument is a good one here,
as newforms is one of the newest chunks of Django. IMO newforms was
being pushed a little before it was ready. What was shipped in 0.96, I
say, was more of a preview of things to come as we only very recently
added support for a major form field that had been missing for several
months (FileField).
I do agree with you, Malcolm, on the other points.
Gary
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
