#19394: Forms in django.contrib.auth have "username" as a hardcoded field value
-----------------------------+--------------------------------------
     Reporter:  dloewenherz  |                    Owner:  nobody
         Type:  Bug          |                   Status:  closed
    Component:  Forms        |                  Version:  1.5-beta-1
     Severity:  Normal       |               Resolution:  wontfix
     Keywords:               |             Triage Stage:  Unreviewed
    Has patch:  0            |      Needs documentation:  0
  Needs tests:  0            |  Patch needs improvement:  0
Easy pickings:  0            |                    UI/UX:  0
-----------------------------+--------------------------------------
Changes (by russellm):

 * status:  new => closed
 * needs_better_patch:   => 0
 * resolution:   => wontfix
 * needs_tests:   => 0
 * needs_docs:   => 0


Comment:

 I completely agree. However, in this case, we're stuck between a rock and
 a hard place.

 These forms are tightly bound to the specific user model, so it's very
 hard to make a truly generic form that will work with all user models. I
 made a design decision to not try and be too smart with this -- I kept the
 UserCreationForm etc simple and username-specific, and documented the fact
 that end-users will need to define their own forms. Given that the form
 logic isn't that complicated (if you look at UserCreationForm, for
 example, most of the code is actually setting up error messages and
 regexes for parsing username), I didn't think it was *that* onerous.

 The one exception to this is the AuthenticationForm -- in that case we're
 using the conceit of calling the "unique identifier field" username,
 regardless of what it is actually called. This makes form processing for
 logins much easier.

 So - absent of a specific proposal to fix the problem -- e.g., showing how
 the form could be refactored -- I'm going to mark this wontfix. If anyone
 can propose a specific way to address this that doesn't result in
 hideously complex code, or an complex class heirarchy that stills require
 a bunch of code to be written, feel free to reopen.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/19394#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to django-updates@googlegroups.com.
To unsubscribe from this group, send email to 
django-updates+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to