On Fri, Jun 3, 2011 at 1:09 PM, Calvin Spealman <[email protected]>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,
> because there is a lot of code expecting it can unpack the choices
> out of 2-tuples.
>
OK, you're right. I was only considering widgets but there are lots of
other things that use choices.
This must be preserved. Perhaps a Choice type could exist, a lot like
> url() in our urls.py files, where we can use a tuple or a special type
> to additional parameters.
>
> choices = (('apples', 'Apples'),
> ('oranges', 'Oranges'),
> Choice('bananas', 'Bananas', disabled=True),
> ('grobblefruit', 'Grobblefruit'))
>
url() in urls.py only works because it's an argument to patterns(), which
understands how to deal with both tuples and RegexURLPattern objects
returned by url(). I don't see how to apply this design to choices without
changing everything that uses choices, which is what we're trying to avoid.
How else can we pass data in to the widget such that it is available to
render_option()? We could add a disabled_choices parameter to the widget's
__init__ class, but then fields (such has ChoiceField) would need to handle
the parameter in the same way they now handle choices.
Changing the choices data structure itself seems like the least bad
alternative, but I'm worried about breaking things that use choices, as you
mentioned.
Cheers,
Jody
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
