Customize is_empty exceptions in a formset or inline formset

[Brian Rosner]

With the removal of core (thank goodness) the FormSet class relies on the Form object to give back a boolean value for an is_empty method call. is_empty accepts an argument exceptions to prevent specific fields from being considered not empty. The problem here is whenever I assign a default value to a field that gets rendered in an inline formset it will always return that it is not empty and try to save it. I am not sure where this customization can fall in, but it seems pretty critical that it needs to be somewhere accessible to prevent this minor headache ;)

[Brian Rosner]

This problem comes full circle back to what is referenced in #5828 about widgets responding to "are you empty?". I am wondering that what is considered empty values should include the default value for a model field?

[Brian Rosner]

This functionality will need to be included before the merge to trunk since it will break inlines for anyone with default values in their models (That are editted inline)

[Antti Kaihola]

One could argue that default values might be provided for all required fields, so all extra forms should be saved if none of the fields are cleared by the user. That would be disastrous user interface design though.

Anyway, here's how the needed logic looks to me:

1. If a field isn't required, it shouldn't be taken into consideration at all when checking if the form is empty. It's up to the developer to ensure there's at least one required field with no default value.

2. If a field is required, the default value should be considered an empty value if all required fields with no default value are empty. The developer must ensure there's at least one required field with no default value.

3. If the default value is invalid, it should always be considered an empty value.

Examples of the three cases in a form with 'name', 'e-mail' and 'occupation' fields, when we know 95% of the users will be blacksmiths:

1. The 'occupation' field defaults to 'blacksmith', but can also be changed to a null or blank value (for ForeignKey or CharField, respectively). The name and e-mail fields have no default values, so they are used to determine if the form has been filled, the 'occupation' field doesn't affect that.

2. We require occupation information for all users, and 'blacksmith' is still the default. If both the name and e-mail fields are blank, 'blacksmith' is considered blank as well and the form is not saved. If either the name or e-mail (or both) are filled, 'blacksmith' is considered a valid value and the form is either saved or an error is displayed for the missing name/e-mail field.

3. The 'occupation' CharField initially displays "(fill your occupation here)", which is not a valid occupation. This default value should always be considered a blank value, since it means the user hasn't touched that field. If the occupation is not required, the user should blank the field to indicate no occupation.

[Karen Tracey <kmtracey@…>]

#6762 was opened reporting the same problem.

[jkocherhans]

This was fixed in [7270]