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

[Thom Wiggers]

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.

[Thom Wiggers]

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

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

[Claude Paroz]

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.