Opened 9 years ago

Closed 9 years ago

#12333 closed (invalid)

CheckboxInput don't work with 0 and 1 value (considerd as Booleans)

Reported by: alexis_m Owned by: nobody
Component: Forms Version: master
Severity: Keywords: CheckboxInput Boolean
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no



I think I've discovered an unwanted behavior in the "render" method of the CheckboxInput class, or maybe I don't understand how it's designed to be used.

When using the render() method, with a value of 0 or 1, the verification process, made by the following code:

if value not in ('', True, False, None):

prevents the "value" attribute to be shown.

It's mainly because 1 and 0 are considéred equals to True and False.

Here is my proposition to solve this:

if (value not in ('', None)) and str(value) not in ('False', 'True'):

Another option can be to use force_unicode from from django.utils.encoding on incoming values.


Attachments (1)

checkbox_input.diff (143 bytes) - added by alexis_m 9 years ago.
diff for the patch proposition

Download all attachments as: .zip

Change History (3)

Changed 9 years ago by alexis_m

Attachment: checkbox_input.diff added

diff for the patch proposition

comment:1 Changed 9 years ago by Benoît Bryon

Additional information about the report.

There are two questions:

  • about a use case : "how to have a MultipleChoiceField that normalizes to something different than a list of unicode values ?"
  • about a code design : "why is this behaviour silent ?"

About the use case

A TypedChoiceField exists, but there is no MultipleTypedChoiceField available.
Subclassing MultipleChoiceField to add TypedChoiceField "coerce" functionality can solve the use case.
Another ticket may be opened to propose such an enhancement.

About "silent" behaviour

It seems that the CheckboxInput widget is designed to handle string/unicode values, such as choices provided by MultipleChoiceField.

If this is a wanted behaviour :

If this an unwanted behaviour :

  • loot at the submitted patch

comment:2 Changed 9 years ago by Russell Keith-Magee

Resolution: invalid
Status: newclosed

Marking invalid because I'm completely confused as to the problem here.

  • The original report doesn't give the use case that causes this to be an issue
  • The patch isn't generated against the root of the source tree
  • There's no test case to validate the new behavior (or explain the problem)
  • I can't see the connection between the problem report and the first comment.

Feel free to reopen if you can provide more details.

Note: See TracTickets for help on using tickets.
Back to Top