On 9/10/07, Nis Jørgensen <[EMAIL PROTECTED]> wrote:
>
> Russell Keith-Magee skrev:
> > On 9/9/07, Amit Upadhyay <[EMAIL PROTECTED]> wrote:
> >
> >> Python unittest TestCase objects have a lot of helper functions like
> >> assert_(), failUnless(), assertEqual(), assertNotEqual() and so on[1].
> If we
> >> had a similar set of helper functions, possibly with more pythonic
> names,
> >> newform validation functions could be written a little more succinctly.
> >>
> >> def clean_password2(self):
> >> if self.clean_data['password1'] != self.clean_data
> ['password2']:
> >> raise ValidationError(u'Please make sure your passwords
> match.')
> >> return self.clean_data['password2']
> >>
> >> can become
> >>
> >> def clean_password2(self):
> >> assert_equal(self.clean_data['password1'],
> >> self.clean_data['password2', "Please make sure your passwords match."
> >> return self.clean_data['password2']
> >>
> >
> > I think a series of helpers for newforms validation is a reasonable
> > idea. I have a few comments about the exact form of your suggestions:
> >
> > - I'm not wild about the deviation from the established camelCase
> > naming convention. The tests are called assertEqual, assertRaises etc
> > in TestCase; although Django generally uses underscores rather than
> > camelCase, I think there would be more value in maintaining
> > similarity.
> >
> > - I'm also inclined to continue the similarities, and make the
> > assertion functions members on BaseForm. This would allow a
> > significant simplification of your proposal, as the data locations
> > (i.e., self.cleaned_data) can be implied.
> >
> > So - as a result of those suggestions, the helpers would look more like:
> >
> > def clean_password2(self):
> > self.assertEqual('password1','password2','Please make sure...')
> > return self.clean_data['password2']
> >
> > Thoughts?
> >
> I don't like the transformation of strings into field values. How would
> you compare a field value to a string?
Exactly my reason for not making it a method of BaseForm. If things were
simple and all validations were such that transfomation of strings into
field value was enough, we would have gotten rid of one or more "
self.clean_data" per statement for one extra "self.". Let me talk in code:
If for some legacy reason, password is supposed to be case in sensitive, we
would want to do:
def clean_password2(self):
self.validate_equal(self.clean_data["password1"].lower(),
self.clean_data["password2"].lower(), "Please make sure..")
return self.clean_data["password2"]
and automatic translation for string to field would not allow it.
I would much rather do:
def clean_password2(self):
d = self.clean_data.get
self.validate_equal(d("password1").lower(), d("password2").lower(),
"Please make sure..")
return d("password2")
and if we are doing such tests all the time, the "self." is just not buying
as anything. And we can make it:
import * from newforms.validation_helpers
def clean_password2(self):
d = self.clean_data.get
validate_equal(d("password1").lower(), d("password2").lower(), "Please
make sure..")
return d("password2")
There is no other reason to refer to self but to automatically translate
strings to field value.
--
Amit Upadhyay
Vakow! www.vakow.com
+91-9820-295-512
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
