[Django] #16149: Allow disabling choices in a <select>
Django
---------------------------+-------------------------------
Reporter: scjody | Owner: nobody
Type: Uncategorized | Status: new
Milestone: | Component: Uncategorized
Version: 1.3 | Severity: Normal
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Easy pickings: 0
---------------------------+-------------------------------
We need to be able to disable choices in a <select>, which is done by
setting the disabled attribute on the <option> tag, for example:
{{{<option value="bananas" disabled="disabled">Bananas</option>}}}
Currently we're doing this by subclassing the Select widget:
http://djangosnippets.org/snippets/2453/
It would be nice if the built in Select widget supported this. One way
would be to replace the existing render_option method with what I've
written, and I can prepare a patch if desired, but this approach changes
the format of the "choices" data structure to something that won't be
understood by other widgets. Perhaps these widgets should be improved
too, but I don't want to do this unless the patch has a chance of being
accepted.
--
Ticket URL: <https://code.djangoproject.com/ticket/16149>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: scjody | Owner: nobody
Type: New feature | Status: new
Milestone: | Component: Forms
Version: 1.3 | Severity: Normal
Resolution: | Keywords:
Triage Stage: Design decision needed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
--------------------------------------------------+------------------------
Changes (by aaugustin):
* needs_better_patch: => 0
* component: Uncategorized => Forms
* needs_tests: => 0
* needs_docs: => 0
* type: Uncategorized => New feature
* stage: Unreviewed => Design decision needed
Comment:
Two remarks about your proposal:
- The API adds some boilerplate; maybe there a good reason, but it's not
immediately obvious.
- You must address carefully the backwards compatibility issue.
Both of these points (and maybe others) require a discussion on the
django-dev mailing list.
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:1>
Django
Reporter: scjody | Owner: scjody
Type: New | Status: assigned
feature | Component: Forms
Milestone: | Severity: Normal
Version: 1.3 | Keywords:
Resolution: | Has patch: 0
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
Changes (by scjody):
* status: new => assigned
* owner: nobody => scjody
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:2>
Django
Reporter: scjody | Owner: scjody
Type: New | Status: assigned
feature | Component: Forms
Milestone: | Severity: Normal
Version: 1.3 | Keywords:
Resolution: | Has patch: 0
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
* cc: shelldweller (added)
Comment:
This should be generic enough to accept any HTML attributes, such as
class, style, id etc. Creating specialized patch for a single attribute
doesn't sound very appealing to me.
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:3>
Django
Reporter: scjody | Owner: scjody
Type: New | Status: assigned
feature | Component: Forms
Milestone: | Severity: Normal
Version: 1.3 | Keywords:
Resolution: | Has patch: 0
Triage Stage: Design | Needs tests: 0
decision needed | Easy pickings: 0
Needs documentation: 0 |
Patch needs improvement: 0 |
-------------------------------------+-------------------------------------
Changes (by scjody):
* ui_ux: => 0
Comment:
Replying to [comment:3 shelldweller]:
> This should be generic enough to accept any HTML attributes, such as
class, style, id etc. Creating specialized patch for a single attribute
doesn't sound very appealing to me.
Thanks for the input. I don't understand the use case for passing these
kinds of attributes to an <option> though. Please contribute to the
discussion on django-developers if you can provide one:
https://groups.google.com/d/topic/django-developers/2E3YuAUotFs/discussion
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:4>
Django
Reporter: scjody | Owner: scjody
Component: Forms | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Design
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by kitsunde):
* cc: kitsunde@… (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:5>
Django
Reporter: scjody | Owner: scjody
Type: New feature | Status: assigned
Component: Forms | Version: 1.3
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
Changes (by aaugustin):
* stage: Design decision needed => Accepted
Comment:
The discussion raised several concerns which must be addressed, but no
one's against the idea.
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:6>
Django
Reporter: scjody | Owner: scjody
Type: New feature | Status: assigned
Component: Forms | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-----------------------------+------------------------------------
* cc: bmispelon@… (added)
Comment:
Just for the record, I've just closed #5116 as a duplicate of this issue.
Its approach was to disable some choices based on their position in the
`choices` list.
I think the approach in this ticket is a bit better, though I would like
it to be more general than simply dealing with the `disabled` attribute.
I think it's a valid use-case to want to add a `class` attriute to an
`<option>` too.
There's also an issue here that I think should be adressed:
Currently, it's perfectly valid to have two `<option>` that have the same
value. With the current patch however, it's not possible to selectively
disable only one of them (since a set of all the values is used under the
hood).
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:7>
Django
Reporter: Jody McIntyre | Owner: (none)
Type: New feature | Status: new
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* owner: Jody McIntyre => (none)
* status: assigned => new
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:8>
Django
Reporter: Jody McIntyre | Owner: (none)
Type: New feature | Status: new
Component: Forms | Version: 1.3
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------+------------------------------------
* cc: Fabio Caritas Barrionuevo da Luz (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/16149#comment:9>