Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4893 closed (wontfix)

remove superfluous field options

Reported by: David S. <dschein@…> Owned by: adrian
Component: Database layer (models, ORM) Version: master
Severity: Keywords: newforms-admin admin fields options validation
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

Field options formerly specific to the admin interface (e.g. blank, choices) remain in the newforms-admin branch. The rationale is that they are or could be more generically useful for data validation. This confuses real database constraints like null with these programmatic 'constraints'. Their applicability is ambiguous.

Looking at the 2 examples, both would be better left to whatever app is working with the data. There is nothing inherent in being able to be blank for example, even in the admin. That is, with the new admin.site functionality, it is perfectly reasonable to imagine that you create 2 admin views for the same model, one of which needs a field to be 'blankable' because it fills the value, while a second view permits the value to be manually entered.

Likewise, 2 admin views might want different choices for a particular field. Specifying choices in the model is either too restrictive or just confusing. Of course, it might be that what you really need is choices modeled in the DB as foreign key lookups, but that further obviates the need for choices at the model level.

Removing these kinds of options will simplify and better focus the model interface.

related links:

Change History (2)

comment:1 Changed 8 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

Disagree, for the reasons mentioned in the thread. I would also question your assumption that the database constraints are the ultimate restriction. They are one layer, not the only one. The existing setup is useful for many purposes and can be not used when you want to have no constraints at all in the model. The options you mention are semantic, not presentational, so the model is the logical place for them.

comment:2 Changed 8 years ago by David S. <dschein@…>

Sure. But for record, there is no assumption that DB constraints are the "ultimate restriction". But there is a difference between those constraints that a database manages---and an ORM supports---and the myriad other constraints that any particular app might consider valuable. Deciding that a few of those myriad other deserve to be elevated into the ORM seems arbitrary, and as mentioned, actually limits their usefulness.

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