Re: Allow disabling choices in a

2020-09-27 Thread Sebastian Van Den Noortgaete
@tony thanks this realy helped me! On Tuesday, 1 May 2018 at 01:33:19 UTC+2 tony...@gmail.com wrote: > This might be a late answer but this is a simplified version that can be > modified using the form instance. > > You can either pass a list of values to be disabled i.e > > def __init__(self,

Re: Allow disabling choices in a

2018-04-30 Thread jackotonye
This might be a late answer but this is a simplified version that can be modified using the form instance. You can either pass a list of values to be disabled i.e def __init__(self, disabled_choices, *args, **kwargs): self.disabled_choices = disabled_choices OR from django.forms

Re: Allow disabling choices in a

2013-01-27 Thread Kit Sunde
It's a bit unexpected that disabled_choices isa frozenset in the patch when choices is a list. Since disabled_choices is a subset of choices, it should be whatever choices is, and it's somewhat common to change choices after init it should be expected that disabled_choices also change. On

Re: Allow disabling choices in a

2011-06-10 Thread Jody McIntyre
Can a core developer please advise on the preferred design here? The main ideas are: 1. Add a 'disabled_choices' attribute to the widget that takes an iterable of choices to disable. I've attached a WIP patch to ticket 16149 following this approach. Optionally this could be passed to the

Re: Allow disabling choices in a

2011-06-07 Thread Jody McIntyre
On Mon, Jun 6, 2011 at 7:49 PM, Chris Beaven wrote: > > I'd say it would be more backwards compatible, and still reasonably concise > to just have a separate attribute: > > disabled_choices = ('bananas',) > OK. I was trying to avoid adding attributes to the widget, but

Re: Allow disabling choices in a

2011-06-06 Thread Chris Beaven
On Saturday, June 4, 2011 4:50:12 AM UTC+12, Jody McIntyre wrote: > > I can't think of a more concise way of clearly representing that 'bananas' > is disabled while still allowing it to have a label [...] > I'd say it would be more backwards compatible, and still reasonably concise to just

Re: Allow disabling choices in a

2011-06-03 Thread Calvin Spealman
On Fri, Jun 3, 2011 at 3:00 PM, Jody McIntyre wrote: > On Fri, Jun 3, 2011 at 1:09 PM, Calvin Spealman > wrote: >> >> > 1. Backwards compatibility is already addressed.  If the widget is >> > passed a >> > regular "choices" field, the existing

Re: Allow disabling choices in a

2011-06-03 Thread Jody McIntyre
On Fri, Jun 3, 2011 at 1:09 PM, Calvin Spealman wrote: > > 1. Backwards compatibility is already addressed. If the widget is passed > a > > regular "choices" field, the existing behavior is preserved. > > Sadly, not true. Any code inspecting the choices is going to break, >

Re: Allow disabling choices in a

2011-06-03 Thread Calvin Spealman
On Fri, Jun 3, 2011 at 12:50 PM, Jody McIntyre wrote: > We need to be able to disable choices in a , which is done by > setting the disabled attribute on the tag, for example: > Bananas > >  Currently we're doing this by subclassing the Select widget: >

Allow disabling choices in a

2011-06-03 Thread Jody McIntyre
We need to be able to disable choices in a , which is done by setting the disabled attribute on the tag, for example: Bananas 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.