> super(ConfirmForm2,self).__init__(*args,**kwargs)
Copy paste edit: ConfirmForm, not with the 2. :)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email
Here's another brainstorm that's sort of a combination. :) It's a
Form that handles confirmation validation, but does so at the field
level. Code will help illuminate what I mean:
class ConfirmForm(forms.Form):
"""
...
"""
def __init__(self, *args, **kwargs):
super(Conf
James,
> While I can understand feeling frustrated at writing custom validation
> methods,
To clarify, I only feel frustrated at writing custom code for
ubiquitous validation needs.
> And that distinction -- between Field-level validation and Form-level
> validation -- also makes intuitive sens
On Mar 16, 2:18 pm, "James Bennett" <[EMAIL PROTECTED]> wrote:
> And that distinction -- between Field-level
> validation and Form-level validation -- also
> makes intuitive sense to me; it feels right
> that a Field only needs to know about itself,
I'm not particularly concerned about field
vali
On 3/16/07, Ian <[EMAIL PROTECTED]> wrote:
> The purpose of web development frameworks is to make common web
> development tasks easier, or give them to you for free. A forms
> framework which requires custom code for password comparisons does not
> satisfy this fundamental requirement.
While I
The purpose of web development frameworks is to make common web
development tasks easier, or give them to you for free. A forms
framework which requires custom code for password comparisons does not
satisfy this fundamental requirement.
I've seen the test codes that tell you how to compare multi
6 matches
Mail list logo
