feature(Field Label): Optionally Allow Field Label to be used In Plac…

[omkar-dsd]

…e of Field Name #6648

By optionally specifying the use_label flag in extra_kwargs, user can set the return field key to be label, which as of now is not configurable and is set to use the field.field_name

Description

• User can now optionally specify in the Meta : extra_kwargs to use field label as the return key.
• use_label flag needs to be set to True. If done so, field.label will be picked as the return field key.
• If use_label is set to True, and label is specified at the same level in the extra_kwargs, the explicitly defined label will be picked. For Example:

class Meta:
    fields = ('example_field',)
    extra_kwargs = {
        `example_field`: {
            'use_label': True, 
            'label': 'My Example Field'
        }
    }

• Moved get_extra_kwargs() from ModelSerializer to its parent Serializer. Also handled the optional Meta class. Makes more sense as extra_kwargs can also be present in Non Model Serializer.

Needs Doc Update.

[rpkilby]

Hi @omkar-dsd. I'm going to close this for a few of reasons:

• Using the label for the field's key name would not be a desirable behavior. Labels are meant purely for descriptive purposes, and are not intended as code values. From the docs:

  label
  A short text string that may be used as the name of the field in HTML form fields or other descriptive elements.

  Since labels are meant to be human readable, they may include whitespace and punctuation. As well, labels are commonly translated based on the user's locale. All of these attributes are useful for labels, but are not useful when using the field name in code.

• Moving get_extra_kwargs() from ModelSerializer to Serializer is incorrect. ORM model inspection solely exists as a feature of ModelSerializers, and it does not make sense to move functionality specific to ModelSerializer to the regular Serializer.

[rpkilby]

Using the label for the field's key name would not be a desirable behavior.

I would further clarify that this would not be a desirable behavior for the framework. If this is useful to you, I would encourage you to create this as a 3rd-party extension.

[omkar-dsd]

There are many requests for this feature. We should optionally allow changing the field name in the response, instead of just making it a hard rule. I agree that the definition of label might not fit in this case, so we can use some other terminology. But such feature is really needed.

[rpkilby]

This functionality has been mentioned in #967, but the feature has been rejected in that PR's form (the introduction a data_key argument, which is similar to your repurposing of label).