Hallöchen!

Luke Plant writes:

> [...]
>
> == Options ==
>
> There were three main courses of action that we talked about on
> django-core.
>
> [...]
>
> = Option 2: Deprecate Meta.exclude, but still allow a missing
> Meta.fields attribute to indicate that all fields should be
> editable.

For our use cases, this would be very unfortunate.  We have many
models in our app, and many fields in most of them.  We "exclude"
most foreign key relationships, and sometimes fields which the user
must not be allowed to change.  Option 2 would mean that we would
have huge name list in 80% of the ModelForms.  Moreover, they needed
to be kept up-to-date, which is very error-prone.

Granted that it's worse if security is affected, but legibility and
DRY would be reduced too drastically in my opinion by option 2.

People in a similar situation like us WILL use

fields = [f.name for f in MyModel._meta.fields if f.name not in ["blah", 
"blubb"]]

but Django should not compel its users to such things.

If you add a new field, your automatic next thought should be how
(and whether) to expose it to the user.  The other way round: If a
developer adds a sensitive field and doesn't look at the code where
the model is made editable to the user, this shows a careless
attitude a library cannot prevent anyway.

Moreover:

> The policy here is essentially this: if any fields the model are
> sensitive, assume all are potentially, and require whitelisting,
> not blacklisting.

I doubt that this is sufficiently frequently true so that it would
justify the reduce of legibility and DRY.  The sensitive fields
usually are special cases, e.g. administrative or internal.  If you
add further fields to a model, however, they are "ordinary" ones.
Well, at least this is my humble assessment and experience.
Therefore, "exclude" does a sensible job for its use case, and is a
reasonable compromise between security and comfort in my opinion.

Tschö,
Torsten.

-- 
Torsten Bronger    Jabber ID: torsten.bron...@jabber.rwth-aachen.de
                                  or http://bronger-jmp.appspot.com

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to