Rick, as a followup;
You also mentioned dynamicly adding fields in __init__, if you also
want to return validation errors, you're better off overriding
_clean_fields() instead of full_clean(). Taking all requirements into
account (processing self.data before any fields are cleaned being the
most important), I think you are looking for something that goes
somewhat like this:
class MyForm(Form):
def _clean_fields(self):
for name, field in self.fields.items():
prefixed_name = self.add_prefix(name)
data_value = self.data.get(prefixed_name, None)
if something_or_other:
self.data[prefixed_name] = .. processed data_value ..
else:
self._errors[name] = self.error_class('something went wrong')
super(MyForm, self)._clean_fields()
If I understood you correctly, you should be able to shape this
according to your needs just fine.
Yuka
On Thu, Apr 14, 2011 at 8:48 PM, Yuka Poppe <y...@xs4all.nl> wrote:
> Hi Rick,
>
> Ok, I did a quick skim over the BaseForm; Validation is called by the
> method is_valid(), which inturn accesses the property self.errors --
> And thus _get_errors() which calls self.full_clean()
>
> full_clean() is responsible for calling the clean method on all
> associated fields, and populating self.cleaned_data. If errors pop up,
> cleaned_data is cleared.
>
> Shawn is correct, you can manipulate self.data right from the
> __init__() method, as long as you make sure you dont touch
> self.is_valid() or self.errors.
>
> However, I would opt to override full_clean() and perform your
> wizardry at self.data there, before calling the parent method; It has
> the added benefit that you are closer to the point where the form
> wants to validate its data, and its thus more trivial to populate the
> error dict with usefull messages for whoever is filling out your form
> -- if something goes wrong, you want your users to be aware, and this
> way you can patch right into the existing validation cycle.
>
> Hope I'm making some sense,
>
> Yuka
>
> On Thu, Apr 14, 2011 at 8:18 PM, ricksteu <rick_s...@yahoo.com> wrote:
>> Hi Yuka - We do want to do the cleaning at the form level, basically
>> because we don't want to use a CharField subclass in all places on all
>> of our forms. You're right, there are two methods that can be
>> overridden: clean() and full_clean(). clean() occurs too late. I
>> think using full_clean() is possible, but it seems like I have to jump
>> through several hoops to make it work. And just I'm looking for a
>> simpler solution.
>>
>> Thanks,
>> Rick
>>
>>
>>
>> On Apr 14, 12:16 pm, Yuka Poppe <y...@xs4all.nl> wrote:
>>> On Thu, Apr 14, 2011 at 5:32 AM, ricksteu <rick_s...@yahoo.com> wrote:
>>>
>>> > Hello -
>>>
>>> > I am looking for a straightforward way to alter posted form data prior
>>> > to when the form's full_clean() method is called. Specifically, I
>>> > need to strip whitespace from any string data (such as for
>>> > CharFields), and this needs to be done prior to when the individual
>>> > fields' clean methods are called.
>>>
>>> Maybe I'm a bit confused, but is it not the fields cleanup method that
>>> would be responsible for actually cleaning up its data, besides
>>> validating?
>>>
>>> If you really must clean it before that, the best way indeed seems to
>>> extend the form and overload its clean method, im not sure wich one,
>>> there's two to look at, I recall the one was more convenient to use
>>> then the other, as it simply just called the other method. It is
>>> indeed responsible for calling the clean method on its fields if I'm
>>> not mistaken, so thats the route I would choose in this case.
>>>
>>> Also yes, you could make a copy of the POST data, modify that and pass
>>> it to the form constructor, but as you mentioned that doesnt seem very
>>> nice way to handle things.
>>>
>>> Hope this is of some assistance.
>>>
>>> --
>>> Regards, Yuka
>>
>> --
>> 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
>> django-users+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/django-users?hl=en.
>>
>>
>
--
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
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en.
