Well the reason passing in self is more work is because when someone
does add_warning() they have to know what the name of the field is in
form, while this isn't a problem for clean_ methods, it is
for clean() methods on the fields themselves, while this could be
worked around by an attribute on t
On Fri, 2008-12-12 at 09:31 -0800, alex.gay...@gmail.com wrote:
> Malcolm,
>
> I've updated the ticket with a newer patch that removes the messy
> globals system, now the form's full_clean() method passes a callable
> to each clean method that accepts it, this callable simply uses
> closure to k
Malcolm,
I've updated the ticket with a newer patch that removes the messy
globals system, now the form's full_clean() method passes a callable
to each clean method that accepts it, this callable simply uses
closure to keep the current field name and it calls the add_warning
method on the form it
Yeah, I see where you're coming from, I'll write up some code based on
this, because I think I follow what you're saying, but did a poor job
describing my thoughts, hopefully code will speak louder than words.
Alex
On Dec 11, 11:29 pm, Malcolm Tredinnick
wrote:
> On Thu, 2008-12-11 at 19:33 -08
On Thu, 2008-12-11 at 19:33 -0800, alex.gay...@gmail.com wrote:
> If it's preferable to pass in a function, (field.clean
> (self.add_warning))
*facepalm*
You aren't explaining what problems you're trying to solve, but just
popping up alternate options. I keep trying to lay out my assumptions
an
If it's preferable to pass in a function, (field.clean
(self.add_warning)) it can be written that way(using either
introspection or trying and catching the type error), I could have it
do that.
To be clear though, it wasn't using thread locals anywhere, it was
simply keying the dictionary on the
On Thu, 2008-12-11 at 19:16 -0800, alex.gay...@gmail.com wrote:
> Right, but if the warn() function is going to be some sort of global
> (as it is now)
> it needs to have some way to store the warnings in the
> intermediary that is thread safe.
So don't make it a global. I really think you're a
Right, but if the warn() function is going to be some sort of global
(as it is now), it needs to have some way to store the warnings in the
intermediary that is thread safe.
Alex
On Dec 11, 10:14 pm, Malcolm Tredinnick
wrote:
> On Thu, 2008-12-11 at 19:10 -0800, alex.gay...@gmail.com wrote:
> >
On Thu, 2008-12-11 at 19:10 -0800, alex.gay...@gmail.com wrote:
> Ok, so basically when someone calls warn() the warning class stores it
> internally in a dictionary(keyed by thread id) in a list of items,
Huh?!
These are warnings raised during form cleaning and normalisation. The
thread id doe
form rendering. So you need to come up with a way for
> > > form creators to specify that (and you've gone for a warning class,
> > > which seems reasonable; there might be other ways, too) and when
> > > validation encounters one of those, it puts it into an approp
ems reasonable; there might be other ways, too) and when
> > validation encounters one of those, it puts it into an appropriate
> > container. That container is then one of the things that form rendering
> > has to deal with. So it needs a way to render the checkbox and allow
>
up with a way for
> form creators to specify that (and you've gone for a warning class,
> which seems reasonable; there might be other ways, too) and when
> validation encounters one of those, it puts it into an appropriate
> container. That container is then one of the things that
be other ways, too) and when
validation encounters one of those, it puts it into an appropriate
container. That container is then one of the things that form rendering
has to deal with. So it needs a way to render the checkbox and allow
manual form layout to do similar.
Validation warnings, if we ha
Over the past few days I've been putting together an implementation of
ticket 23[1]. I realise this isn't on the 1.1 features list, but I'd
still like to solicit any thoughts people have. Right now the API is
that in any form validation method you can using the warning system,
it works by:
from
14 matches
Mail list logo
