Well, I think it's clear what I see. I sort of disagree about the
impl, design, call it what you will.
Specifically, the current impl makes testing harder than it needs to
be, or at least the testing that I'd like to do. That is, I have a
field, that field has validation rules and I'd like to test that the
work. Strictly a field has 2 sets of validation rules, those on the
field itself (or is it more correct to say on the widget), and a
(possibly empty) set of rules defined by the form creator (call them
creator validations).
So a couple of issues about this.
First, the cleaned_data attribute (member?) is not guaranteed to be
populated fully at the time any creator validation is called. That is,
if I have 2 dependent fields, say password1, password2, I cannot get
cleaned_data['password2'] inside of the creator validator
clean_password1() unless/until the full_clean() impl get's to the
field password2. Thus the ordering of fields and the impls of
clean_xxx() are coupled in what I'd call a non-obvious fashion. This
seems unnecessary but that's just me.
Second this tends to make righting unit tests rather more error prone.
Or at least the sort of tests I'm used to writing. I realize there are
various idiomatic ways of dealing with the problems I'm having
(spelunk the error list, etc) but certainly I can imagine better ways.
Keep in mind I'm not at all a python person (yet) so this may in fact
be entirely infeasible. But presumably one can do something like
declare clean_xxx as follows:
def clean_something(self, password1, password2):
# Stuff
Provided one can get to the names of the arguments it seems then that
it would be useful to do something in full_clean() like
for each argument in the args list of each clean_xxx method:
name = arg name
if there_is_a_field_named(name):
set the value of that argument to field.clean()
else:
raise somethingorother
I like this in several dimensions, much as I'd like faster-than-light
travel, which is to say it would be really cool but I don't see how to
get there from here.
Anyway, I can see several ways around this and I'll pick one or the
other. OTOH, if testing at this level of granularity is inconsistent
with the python/djano world view, I would love to hear what's better.
Understanding code is easy(ish), philosophy is hard.
Thanks for the pointer to the errorlist.
Apologies if this makes no sense at all. I am not, again, a python/
django person.
---Rick
On Nov 4, 2008, at 10:32 AM, Karen Tracey wrote:
> On Tue, Nov 4, 2008 at 12:07 PM, Rick <[EMAIL PROTECTED]> wrote:
>
> Give a man a fish...
>
> Right, so I see now what's going on. Is this the right place to argue
> about how this works?
>
> It isn't clear what you see or what you want to argue about?
>
> cleaned_data is established when the form is validated and is
> deleted if the entire form does not pass validation (though I think
> there is a ticket open that asks for cleaned_data to stick around
> with the valid values that did pass validation, so that might change).
>
> There is no way to validate part of a form -- it is all-or-nothing.
> If you want to check for an error on a specific field, then check
> for the existence of that field's name in the errors dictionary
> after calling is_valid(). (You can also verify that you get the
> exact error message you are looking for, if you like.)
>
> Karen
>
>
> ---Rick
>
>
> On Nov 4, 8:46 am, Rick Kitts <[EMAIL PROTECTED]> wrote:
> > Thanks, it does but this is a bad test methodology. is_valid()
> > verifies the entire form and there is no way of knowing in the
> test if
> > the validation is failing because of other reasons or the specific
> one
> > I (think) I'm testing.
> >
> > I guess the broader question then is when is cleaned_data
> established?
> > It appears transient since if I call the clean_xxx() method after
> > calling is_valid() then I still get the attriberr.
> >
> > ---Rick
> >
> > On Nov 4, 2008, at 5:10 AM, Dan Fairs wrote:
> >
> >
> >
> > >> Running the test causes a splash of barf that says:
> >
> > >> AttributeError: 'TheFormClass' object has no attribute
> 'cleaned_data'
> >
> > > Try calling form.is_valid() (which should in addition return
> whether
> > > the validation framework as a whole thought the form was valid).
> This
> > > should invoke your clean_ method.
> >
> > > Cheers,
> > > Dan
> >
> > > --
> > > Dan Fairs <[EMAIL PROTECTED]> |http://www.fezconsulting.com/
> >
> >
>
>
>
> >
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" 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-users?hl=en
-~----------~----~----~----~------~----~------~--~---
