Opened 9 years ago

Closed 8 years ago

#18337 closed New feature (wontfix)

django.forms.BoundField should be injectable within django.forms.Form

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


I would like to create the following html from a single reusable field

<div class="contactnumber colourless" id="id_friends_parent">
    <input type="checkbox" name="friends" id="id_friends">
    <label for="id_friends">Friends (156)</label>
<script type="text/javascript">
    $('#id_friends').click(function() { $('#id_friends_parent').removeClass('colourless'); if (this.checked) { console.log('checked'); } else { console.log('not checked');$('#id_friends_parent').addClass('colourless'); } });

In order to keep the label html in the BoundField and the widget html in the widget and to allow a mechanism for adding wrapping html to a field widget it would seem elegant to allow access to BoundField by making BoundField an overridable property in the django.forms.BaseForm class in the same way the widget property is overridable in the Field class.

Change History (6)

comment:1 Changed 9 years ago by eamonnfaherty

I have opened a pull request with a patch.

comment:2 Changed 9 years ago by eamonnfaherty

Cc: eamonnfaherty added

comment:3 Changed 9 years ago by eamonnfaherty

Has patch: set

comment:4 Changed 8 years ago by Luke Plant

Easy pickings: unset
Triage Stage: UnreviewedDesign decision needed
Type: Cleanup/optimizationNew feature

This is not easy pickings. If we expose the attribute you suggest, we also need to document the entire interface of BoundClass ("docs or it doesn't exist"), and test it independently ("tests or it doesn't work").

I suspect if we look at it, we'll find that BoundField doesn't really have an interface suitable for this purpose, but is best kept as implementation detail. I'm tempted to close WONTFIX, but will instead move to DDN. It belongs to a class of possible solutions to the problem of customising form rendering, and I'm not sure it is the most robust one.

comment:5 Changed 8 years ago by Luke Plant

There has been no progress here, so I'm going to move to WONTFIX for the reasons described. It looks like an unlikely solution to the problem, and it would tie us down to backwards compatibility with an implementation detail.

comment:6 Changed 8 years ago by Łukasz Rekucki

Resolution: wontfix
Status: newclosed

You forgot something ;)

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