I agree with Marc on this one - I remember doing the work to change
"ModelForm.fields" so that you needed "__all__" to indicate everything,
instead of defaulting to all. This was a nightmare precisely because of
the different number of ways of defining the fields. This is partly the
result of retrofitting ModelAdmin to use ModelForms, which it didn't
originally.
Just implementing ModelAdmin.get_exclude() might prove to be extremely
difficult to do, especially when you need to document how it interacts
with all the other ones.
I think the problems with the false negatives for the admin checks may
need to be solved another way - namely by removing them. That's
unfortunate, but I found them tricky in the past - they may prevent
common errors, but they also prevent more advanced ways that you might
want to use the admin.
Luke
On 06/06/15 14:42, Marc Tamlyn wrote:
I don't think we should add this. Exclude is passed to the form, and
we already have a way of changing the form based on the request. I'd
rather see changes made to reduce some of the many many ways to select
fields in the admin. By my count at present we have:
ModelAdmin.fields
ModelAdmin.get_fields()
ModelAdmin.exclude
ModelAdmin.fieldsets
ModelAdmin.get_fieldsets()
ModelAdmin.readonly_fields
ModelAdmin.get_readonly_fields()
ModelAdmin.form concrete fields
ModelAdmin.form.Meta.fields
ModelAdmin.form.Meta.exclude
ModelAdmin.get_form()
There's an argument the only one missing here is get_exclude(), but I
think the current API is silly. Personally, I'd like to see us moving
towards us encouraging doing more work in the form (and defining the
form) rather than doing so much in the ModelAdmin class. This may well
require better support for fieldsets in django.forms.
Marc
On 6 June 2015 at 05:06, Peter Farrell <[email protected]
<mailto:[email protected]>> wrote:
We are writing a custom admin for CleanerVersion that subclasses
ModelAdmin. Just about every attribute has a hook method which
makes extension easier. For example, list_display has
get_list_display(). However, exclude doesn't have one implemented
and it seems like an oversight. I'm proposing we add one.
Our current work seeking is to write a property descriptor for
exclude but then the admin check fails with it not being a tuple
or list. Then you have to create a custom admin checks class to
suppress the exclude check error because it's not a tuple or list
(but really a descriptor).
If this is ok, I'Ill write a PR.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to [email protected]
<mailto:django-developers%[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/c1e8762d-1c9f-47e9-8fe7-e9761c27e057%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to [email protected]
<mailto:[email protected]>.
To post to this group, send email to
[email protected]
<mailto:[email protected]>.
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMwjO1HKDr6T9BKf-%2B4rNm6775S7akyHfC%2BNEk4sqSDw8cOb%2Bg%40mail.gmail.com
<https://groups.google.com/d/msgid/django-developers/CAMwjO1HKDr6T9BKf-%2B4rNm6775S7akyHfC%2BNEk4sqSDw8cOb%2Bg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
"He knows the way I take: when he has tried me, I shall come forth
as gold" (Job 23:10).
Luke Plant || http://lukeplant.me.uk/
--
You received this message because you are subscribed to the Google Groups "Django
developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/55843AC1.4040707%40cantab.net.
For more options, visit https://groups.google.com/d/optout.
