On 13 June 2012 09:16, Luke Plant <[email protected]> wrote:
> = Option 2: Deprecate Meta.exclude, but still allow a missing
> Meta.fields attribute to indicate that all fields should be editable.
>
> The policy here is essentially this: if any fields the model are
> sensitive, assume all are potentially, and require whitelisting, not
> blacklisting.
>
+1 for option 2 as I've always felt like Meta.exclude was the wrong way to
do go building a ModelForm which was supposed to have a subset of fields.
Given that the underlying Model definition may change, it would be easy to
all of a sudden expose a newly added field. This would be particularly bad
when in your template you use {{ form.as_p }} or similar. I never use
Meta.exclude for this reason, always giving a whitelist anyway.
+0 for option 3 as I think the convenience of a missing Meta.fields is
worthwhile, but I could live without it.
Another option could be to split ModelForm such that you could mix and
match the functionality you require. Moving forward the ModelForm class
could provide option 3 behaviour, and a newly introduced class could
provide the option 2 behaviour. The only difference would be the alias to
Meta.fields not existing results in all model fields, but this would be an
explicit step.
Gary
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
