Opened 17 years ago

Closed 17 years ago

#5878 closed (fixed)

Customize is_empty exceptions in a formset or inline formset

Reported by: Brian Rosner Owned by: nobody
Component: Forms Version: newforms-admin
Severity: Keywords: nfa-blocker
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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 ;)

Change History (5)

comment:1 by Brian Rosner, 17 years ago

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?

comment:2 by Brian Rosner, 17 years ago

Keywords: nfa-blocker added
Triage Stage: UnreviewedAccepted

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)

comment:3 by Antti Kaihola, 17 years ago

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

comment:4 by Karen Tracey <kmtracey@…>, 17 years ago

#6762 was opened reporting the same problem.

comment:5 by jkocherhans, 17 years ago

Resolution: fixed
Status: newclosed

This was fixed in [7270]

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