Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#19655 closed New feature (wontfix)

Need HTML id's needed for all admin forms

Reported by: nu.everest@… Owned by: nobody
Component: contrib.admin Version: 1.4
Severity: Normal Keywords: custom admin Javascript JQuery HTML id class AJAX
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: yes UI/UX: no

Description

Creating custom Javascript for django admin forms can be difficult. This is primarily due to the fact that many of the HTML tags in the HTML generated by django admin do not have unique classes or id's.

For example, if a programmer needs to hide an element in the browser based on a users dynamic choice; then the easiest thing to do is use JQuery's .hide() function. Given the django admin generated HTML below a programmer would use the Javascript $("div.field-somefield1").hide(); to hide all DIVs associated with the class="field-somefield1".

<fieldset class="module aligned ">
    <h2>Frequency</h2>
        <div class="form-row field-somefield1"></div>
</fieldset>

<fieldset class="module aligned ">
    <h2>Applicable days</h2>
        <div class="form-row field-somefield2"></div>
</fieldset>

Issue:
However, if the programmer wishes to hide a <fieldset> or an <h2> using .hide() they will have to do some sort of convoluted Javascript 'hack' that checks the content of the fieldset OR counts the fieldsets because the django admin makes all of the fieldset's and h2's appear identical at the tag level.

Proposed Solution:
The fix for this seems very simple and straightforward. Just add unique id's to each element generated by django admin.

Change History (3)

comment:1 by Luke Plant, 11 years ago

I'm not convinced a solution is that straightforward.

Assuming a mechanism for generating unique ids is easy (which it might not be, but probably is), unique ids might not be good enough - for example, you can generate unique ids using increasing integers, but this would be fragile with respect to adding new fieldsets - you will be more likely to want to use names.

Also, we really need to get it right first time, or we will break code that relies on the previous strategy for ids.

In fact, jQuery code that finds a relevant field and works back to the parent fieldset is quite easy:

    $('.field-somefield').parent('fieldset')

This would probably be more robust than using integer ids on field sets.

So, at the moment I'm not sure whether to accept this. If a useful and robust strategy for naming fieldsets can be provided, then I think this should be accepted.

comment:2 by Claude Paroz, 11 years ago

Resolution: wontfix
Status: newclosed

I do agree with Luke. If you have a real use case, please describe the precise problem you are facing, with code example showing that it is not possible to target a specific DOM element and create a ticket for the specific issue.

comment:3 by nu.everest@…, 11 years ago

Agreed. No change is necessary. I was completely ignorant of the JQuery .parent('fieldset') function.

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