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
widget
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 it's
definitely backwards
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,
> because there is a lot
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. One
Now that Django has logging support using the Python logging module,
it would be nice if the unit testing framework included the ability to
capture logs, similarly to the mail.outbox functionality.
I am aware of the log_capture decorator in the testfixtures package,
and we are using it for some te
