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.
