Opened 13 years ago

Last modified 23 months ago

#16149 new New feature

Allow disabling choices in a <select>

Reported by: Jody McIntyre Owned by:
Component: Forms Version: 1.3
Severity: Normal Keywords:
Cc: Sergiy Kuzmenko, kitsunde@…, bmispelon@…, Fabio Caritas Barrionuevo da Luz Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

select_with_disabled.diff (1.7 KB ) - added by Jody McIntyre 13 years ago.
WIP patch

Download all attachments as: .zip

Change History (10)

comment:1 by Aymeric Augustin, 13 years ago

Component: UncategorizedForms
Triage Stage: UnreviewedDesign decision needed
Type: UncategorizedNew feature

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.

comment:2 by Jody McIntyre, 13 years ago

Owner: changed from nobody to Jody McIntyre
Status: newassigned

by Jody McIntyre, 13 years ago

Attachment: select_with_disabled.diff added

WIP patch

comment:3 by Sergiy Kuzmenko, 13 years ago

Cc: Sergiy Kuzmenko added

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.

in reply to:  3 comment:4 by Jody McIntyre, 13 years ago

UI/UX: unset

Replying to 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

comment:5 by Kit Sunde, 11 years ago

Cc: kitsunde@… added

comment:6 by Aymeric Augustin, 11 years ago

Triage Stage: Design decision neededAccepted

The discussion raised several concerns which must be addressed, but no one's against the idea.

comment:7 by Baptiste Mispelon, 11 years ago

Cc: bmispelon@… added

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).

comment:8 by Mariusz Felisiak, 2 years ago

Owner: Jody McIntyre removed
Status: assignednew

comment:9 by Fabio Caritas Barrionuevo da Luz, 23 months ago

Cc: Fabio Caritas Barrionuevo da Luz added
Note: See TracTickets for help on using tickets.
Back to Top