Re: Need straightforward way to pre-process form data

[ricksteu]

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  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  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  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  wrote:
> >>> On Thu, Apr 14, 2011 at 5:32 AM, ricksteu  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 

Re: Need straightforward way to pre-process form data

[Daniel Roseman]

On Thursday, April 14, 2011 7:09:57 PM UTC+1, ricksteu wrote:
>
> Shawn - The validation appears to actually takes place *before* the 
> __init__ is called (during instantiation, not during initialization.) 
> If you look at BaseForm, scroll past the __init__() method, and you'll 
> see: 
>
> def _get_errors(self): 
> "Returns an ErrorDict for the data provided for the form" 
> if self._errors is None: 
> self.full_clean() 
> return self._errors 
> errors = property(_get_errors) 
>
> That last line calls _get_errors() which in turn calls full_clean(). 
> (I could totally be missing something) 
>
> Rick


Yes, you are. That last line doesn't call get_errors() at all - you can see 
there are no calling parentheses after the method name. It's simply the old 
(pre-2.4) way of defining a decorator.
--
DR. 

-- 
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.

Re: Need straightforward way to pre-process form data

[Yuka Poppe]

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  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  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  wrote:
>>> On Thu, Apr 14, 2011 at 5:32 AM, ricksteu  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.

Re: Need straightforward way to pre-process form data

[Yuka Poppe]

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  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  wrote:
>> On Thu, Apr 14, 2011 at 5:32 AM, ricksteu  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.

Re: Need straightforward way to pre-process form data

[ricksteu]

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  wrote:
> On Thu, Apr 14, 2011 at 5:32 AM, ricksteu  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.

Re: Need straightforward way to pre-process form data

[ricksteu]

Shawn - The validation appears to actually takes place *before* the
__init__ is called (during instantiation, not during initialization.)
If you look at BaseForm, scroll past the __init__() method, and you'll
see:

def _get_errors(self):
"Returns an ErrorDict for the data provided for the form"
if self._errors is None:
self.full_clean()
return self._errors
errors = property(_get_errors)

That last line calls _get_errors() which in turn calls full_clean().
(I could totally be missing something)

Rick



On Apr 14, 12:07 pm, Shawn Milochik  wrote:
> No data validation takes place any time during __init__, so it's not too late.

-- 
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.

Re: Need straightforward way to pre-process form data

[Yuka Poppe]

On Thu, Apr 14, 2011 at 5:32 AM, ricksteu  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.

Re: Need straightforward way to pre-process form data

[Shawn Milochik]

No data validation takes place any time during __init__, so it's not too late.

-- 
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.

Re: Need straightforward way to pre-process form data

[ricksteu]

Shawn - thanks for the reply, but the field cleaning occurs prior to
the super().__init__.  It occurs in the form definition.  So,
performing manipulation afterward would be too late.

The main problem with performing the manipulation after the field
cleaning is that I don't want a CharField with pure whitespace to pass
validation, then have the whitespace stripped afterward.  I want the
whitespace to be stripped first and then, because the value is now
blank, fail the 'required' field validation rule.

Rick




On Apr 14, 11:20 am, Shawn Milochik  wrote:
> I believe you can customize your form's __init__ to handle this.
>
> In the __init__, call the super() __init__ and then do your dynamic field 
> jazz.
>
> After that, you should be able to manipulate the data.

-- 
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.

Re: Need straightforward way to pre-process form data

[Shawn Milochik]

I believe you can customize your form's __init__ to handle this.

In the __init__, call the super() __init__ and then do your dynamic field jazz.

After that, you should be able to manipulate the data.

-- 
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.