#2723: yes/no option for BooleanField
----------------------------------------------------------+-----------------
          Reporter:  Gary Wilson <[EMAIL PROTECTED]>  |         Owner:  shanx   
                                
            Status:  assigned                             |     Milestone:  
post-1.0                                
         Component:  django.contrib.admin                 |       Version:  SVN 
                                    
        Resolution:                                       |      Keywords:  
nfa-someday, sprintdec01, sprint-pycon08
             Stage:  Accepted                             |     Has_patch:  1   
                                    
        Needs_docs:  0                                    |   Needs_tests:  0   
                                    
Needs_better_patch:  1                                    |  
----------------------------------------------------------+-----------------
Changes (by mtredinnick):

  * needs_better_patch:  0 => 1
  * stage:  Ready for checkin => Accepted

Comment:

 This shouldn't be supplying a widget only for the admin interface. Will no
 other application ever use boolean fields? If we're adding a widget, it's
 generally going to either be worthy of putting into
 `django/forms/widgets.py` or not including at all; there are very few
 cases when a specialised widget just for admin is appropriate.

 So, let's move the widget to a more useful place.

 Secondly, the tests here are kind of confusing (all the hooked widget
 stuff). They seem to be trying to enforce something about admin widget
 overrides that I'm not sure is actually correct (why can't those things
 ever change?). Whilst tests are good, those tests aren't testing that this
 widget behaves correctly; they're trying to test some other incidental
 behaviour. So let's move those to another patch so that when we resolve
 how to do better custom widget overrides in admin they can be part of
 that. At the moment they're distracting a bit from the issue at hand and
 I'm not sure that if they were to fail it would actually mean there's a
 problem in Django's public behaviour (they're internal implementation
 details, as far as I can tell).

 Thirdly, it looks unnecessary to have strings like `u'1'` for the choices.
 Just use integers there. The point is that there's no need to do all this
 forcing to strings and it makes the reader wonder why you're doing that.
 If you used 0 and 1 for the choice values, then you'd simplify a lot of
 the code, too, since `bool(value)` would give the right integer -> boolean
 conversion and `int(value)` would give the right choice value for both
 boolean and integer input.

 Finally, please don't mark your own patches as "ready for checkin". I
 suspect this went unreviewed for so long because it was in that state and
 we hadn't realised it hadn't been through a review.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/2723#comment:14>
Django <http://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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to