Passing external data to Form objects in newforms
Benjamin Slavin
for validation.
Consider, for example, a 'change password' form.
Validation of the current password is required to ensure correct authorization.
To validate the current password, the form needs to know the user it
is validating against.
I have suggested an enhancement to newforms that would potentially
solve this issue.
Please see the ticket located at:
http://code.djangoproject.com/ticket/3479
In terms of coding this, it's a trivial change with tremendous benefit
for users and wouldn't hurt backwards compatibility within newforms.
If there's support, I'll be happy to put together a patch.
- Ben
Honza Král
is this really necessary ? since you always subclass formsForm, why
wouldn't you use:
class PasswordChangeForm(forms.Form):
def __init__( self, user, *args, **kwargs ):
super(PasswordChangeForm, self ).__init__( *args, **kwargs)
self.user = user
I agree that its a little bit more typing, but its also more generic
and doesn't add functionality that will be left unused in 9 uses out
of ten.
just my 2c's...
>
> - Ben
>
> >
>
--
Honza Král
E-Mail: Honza...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
Benjamin Slavin
>
> is this really necessary ? since you always subclass formsForm, why
> wouldn't you use:
> class PasswordChangeForm(forms.Form):
> def __init__( self, user, *args, **kwargs ):
> super(PasswordChangeForm, self ).__init__( *args, **kwargs)
> self.user = user
Actually, your suggestion was my original approach.
The primary benefit of your suggestion is that it ensures that the
arguments are passed (not as much checking is required in the form).
> I agree that its a little bit more typing, but its also more generic
> and doesn't add functionality that will be left unused in 9 uses out
> of ten.
I agree with your evaluation that it won't be used in 9 out of 10
cases... but that still means a usage rate of 10%. I do feel that
this is a common usage pattern.
The reason that I make the suggestion is that I found myself using
this functionality (overriding __init__) in a number of places (clear
violation of DRY). Aside from the DRY aspect, I don't like the idea of
asking newbies to override __init__ for a common case.
Also, this functionality has very low overhead... the diff for my
current implementation (without tests or docs) is two lines.
- Ben
Honza Král
>
> On 2/11/07, Honza Král <honza...@gmail.com> wrote:
> >
> > is this really necessary ? since you always subclass formsForm, why
> > wouldn't you use:
> > class PasswordChangeForm(forms.Form):
> > def __init__( self, user, *args, **kwargs ):
> > super(PasswordChangeForm, self ).__init__( *args, **kwargs)
> > self.user = user
>
> Actually, your suggestion was my original approach.
>
> The primary benefit of your suggestion is that it ensures that the
> arguments are passed (not as much checking is required in the form).
>
> > I agree that its a little bit more typing, but its also more generic
> > and doesn't add functionality that will be left unused in 9 uses out
> > of ten.
>
> I agree with your evaluation that it won't be used in 9 out of 10
> cases... but that still means a usage rate of 10%. I do feel that
> this is a common usage pattern.
>
> The reason that I make the suggestion is that I found myself using
> this functionality (overriding __init__) in a number of places (clear
> violation of DRY). Aside from the DRY aspect, I don't like the idea of
> asking newbies to override __init__ for a common case.
I am mortified when thinking about people that cannot override
__init__ in a blink of an eye doing actual programming. ;) (look where
it got PHP ;) )
> Also, this functionality has very low overhead... the diff for my
> current implementation (without tests or docs) is two lines.
true, but what would happen if you added two lines (or worse - an
extra argument to a generic function/method) for everything that 10%
of people would use and is easily (even though maybe little clumsily)
done without it? Certainly nothing I would want to use (subjectively).
I personally love the fact, that Django is simple, no feature bloat,
everything is as simple as possible while maintaining 100% usability.
It's just my personal opinion, but from the look of the code its
shared among others as well.
Benjamin Slavin
>
> true, but what would happen if you added two lines (or worse - an
> extra argument to a generic function/method) for everything that 10%
> of people would use and is easily (even though maybe little clumsily)
> done without it? Certainly nothing I would want to use (subjectively).
To clarify, I wasn't saying that 10% of users would make use of this
functionality... just 10% of -forms-. In terms of the number of
people that would benefit from this, I think it would be -much higher-
than 10%. Maybe I'm wrong, but that's why I brought it up to discuss.
In terms of your hypothetical 'what would happen', I don't think it's
a fair question in this case. My suggestion provides a generic
interface for passing in external data... a common and useful design
pattern. I think your question would be fair if I was asking to add a
'user=' argument or something similar, but I'm not.
> I personally love the fact, that Django is simple, no feature bloat,
> everything is as simple as possible while maintaining 100% usability.
>
> It's just my personal opinion, but from the look of the code its
> shared among others as well.
No argument here. These were the reasons I picked Django over its
competitors. I don't feel that my suggestion goes against these
principles.
- Ben
Adrian Holovaty
> http://code.djangoproject.com/ticket/3479
>
> In terms of coding this, it's a trivial change with tremendous benefit
> for users and wouldn't hurt backwards compatibility within newforms.
> If there's support, I'll be happy to put together a patch.
As Honza suggested, you're already able to do this in a *much* more
generic fashion by simply subclassing the form and implementing
__init__(). I'm marking the ticket as a wontfix.
If you're in love with the idea, you can create your own Form
subclass, and just subclass it instead of Form whenever you use forms.
Object-oriented programming is cool. :-)
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Benjamin Slavin
>
> As Honza suggested, you're already able to do this in a *much* more
> generic fashion by simply subclassing the form and implementing
> __init__(). I'm marking the ticket as a wontfix.
Fair enough.
Is there any interest in adding this to the newforms documentation?
You, Honza, and I came up with a workable solutions quite quickly, but
from what I've seen, most Django users are using Python for the first
time. I don't know how easily they would be able to solve this
problem.
I don't mind putting together some documentation to help newbies, but
I figured I'd test the waters before committing the effort. Thoughts?
- Ben
whiteinge
(i.e. the opposite of the logical, preferred order), I would really
love documentation on this sort of thing. I wrote a hackish workaround
to a very similar problem just yesterday which I can currently
updating with your example in mind. :-)
Thanks!
- whiteinge
On Feb 11, 9:27 pm, "Benjamin Slavin" <benjamin.sla...@gmail.com>
wrote: