Opened 16 years ago

Closed 11 years ago

#9079 closed New feature (wontfix)

Label tag attributes

Reported by: oggy Owned by: nobody
Component: Forms Version: 1.0
Severity: Normal Keywords: form label label_tag
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

label_tag_r9027.diff (1.9 KB ) - added by oggy 16 years ago.

Download all attachments as: .zip

Change History (8)

by oggy, 16 years ago

Attachment: label_tag_r9027.diff added

comment:1 by Adrian Holovaty, 16 years ago

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.

comment:2 by oggy, 16 years ago

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?

comment:3 by Jacob, 15 years ago

Triage Stage: UnreviewedDesign decision needed

comment:4 by Luke Plant, 13 years ago

Severity: Normal
Type: New feature

comment:5 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:6 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:7 by Carl Meyer, 11 years ago

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top