@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,
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
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
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
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
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
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
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,
>
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:
>
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.
10 matches
Mail list logo