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

[eamonnfaherty]

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>
</div>
<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'); } });
</script>

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.

[eamonnfaherty]

I have opened a pull request with a patch.

​https://github.com/django/django/pull/77

[Luke Plant]

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.

[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.

[Łukasz Rekucki]

You forgot something ;)