Yuka and Shawn - Thanks very much for your help! Overriding
_clean_fields() does satisfy the requirements (including the dynamic
fields).
Rick
On Apr 14, 2:54 pm, Yuka Poppe <y...@xs4all.nl> wrote:
> 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
> >> athttp://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.
