remove superfluous field options

[David S. <dschein@…>]

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:

• ​http://groups.google.com/group/django-users/browse_thread/thread/ccec4062d37bcae7/7fc869b45ac8c983#7fc869b45ac8c983

[Malcolm Tredinnick]

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.

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