Label tag attributes

[oggy]

Add the label_tag_attrs parameter to the Field init, to provide a convenient way of adding, say 'class="required"' to the generated label tag.

[Adrian Holovaty]

Hmm, this seems a bit crufty. I'm inclined to favor a more generic approach to editing the HTML, like Simon Willison's template tag library.

[oggy]

I gave a more detailed rationale for this in this django-dev post:

​http://groups.google.com/group/django-developers/t/ead13c9424b279a2

As always, there are some other takes on the issue there. Anyhow here's the crux of my argument:

• there's currently no provision for adding any attributes to automatically generated label tags. This includes, but is not limited to the "class" attribute - other attributes are useful as well (e.g. how do you initially completely hide a sometimes-necessary AJAX field otherwise - along with its label?)
• conceptually, I agree that this shouldn't go there as we should let the designers have full control of the presentation. However, in order for the form to function at all, the programmer needs to select a widget, relinquishing designers' control of the design to begin with. In order not to lose the control completely, you end up needing to add "attrs" to the Widget constructor. Let's be consistent and do the same for the label - it's not creating a bigger wart than the one that already exists, and it's IMHO pretty convenient as well.
• it's certainly no more crufty than admin.helpers.AdminField

Somewhat related to this, BoundField.label_tag currently accepts an attrs parameter but that's not used anywhere in the code. Is it a remnant of some similar idea that never caught on?

[Aymeric Augustin]

Change UI/UX from NULL to False.

[Aymeric Augustin]

Change Easy pickings from NULL to False.

[Carl Meyer]

This is a convenience, but it doesn't allow you to do anything that you can't already do today by bypassing the default all-in-one form rendering and taking finer-grained control of the rendering. It should be assumed that this is necessary when you have advanced rendering needs.

This change may not be inherently more hackish than what is already present, but it adds one more public API for specifying presentation details via Python code, which is one more bad API we have to support on into the future, even if at some point we're able to move to a system where form presentation is handled in templates instead of Python code.