Opened 6 years ago

Closed 6 years ago

#23445 closed Bug (wontfix)

Removing a key from Form.fields keyOrder no longer hides elements

Reported by: Thom Wiggers Owned by: nobody
Component: Forms Version: 1.7
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

There was a bit of undocumented behaviour in using the SortedDict's keyOrder that allowed it to be used to hide fields on rendering a form. Since this now uses collections.OrderedDict this behaviour has been broken (along with the rest of keyOrder):

Example:

class BlaForm(Form):
    field_a = CharField(...)
    field_b = CharField(...)

    def __init__(*args, **kwargs):
        self.fields.keyOrder.remove('field_a')

This would make it not show up in the rendered form at all. Somewhere later you could still access the (initial) value of field_a:

form.cleaned_data['field_a']

This is not possible if you use del to remove the field from self.fields, the normal way to do this.

This feature was pretty useful when subclassing forms that had more fields than you needed in all versions while sharing data processing stuff.

This was undocumented behaviour, so this functionality might not need to be restored. However, a note on the 'breaking changes' page is warranted, imho.

There is also still a reference to keyOrder on https://code.djangoproject.com/wiki/CookBookNewFormsFieldOrdering.

Change History (3)

comment:1 Changed 6 years ago by Thom Wiggers

The keyOrder approach is also popular on StackOverflow: http://stackoverflow.com/a/1133470/248065

comment:2 Changed 6 years ago by Aymeric Augustin

This was a private API -- the only results on https://docs.djangoproject.com/search/?q=keyOrder&release=9 come from the source code.

Changes to private APIs aren't documented (that's the point of defining a subset of APIs as public). Sometimes we're making exceptions when we're removing large amounts of code that we know are widely used, because no good public API exists, but I don't think this example crosses the threshold.

Being popular on StackOverflow is often synonym with being wrong. The wiki also tends to gather obsolete or inappropriate advice. We can't commit to supporting anything that has been mentioned online.

My inclination would be to close this as wontfix to avoid setting a precedent.

comment:3 Changed 6 years ago by Claude Paroz

Resolution: wontfix
Status: newclosed

I was about to answer along the same lines. When you're using a hack, you should be prepared for such happenings.

If you think we can improve things in Django to answer this use case, feel free to open a separate ticket with a proposal.

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