Discussion:
Dynamic inlines for Django ModelAdmin
(too old to reply)
Gert Steyn
2015-07-27 01:52:27 UTC
Permalink
Hi All

I've been using Django since before newforms-admin and have seen ModelAdmin
gradually becoming more customization. I often use dynamic inlines (based
on the state of the object) and would like to clean up the implementation a
bit.

I would like to open a ticket to add:

def get_inlines(self, request, obj=None):
return self.inlines

to ModelAdmin and then change

def get_inline_instances(self, request, obj=None):
inline_instances = []
for inline_class in *self.inlines*:

to

def get_inline_instances(self, request, obj=None):
inline_instances = []
for inline_class in *self.get_inlines(request, obj=obj)*:

Any reasons not to do this?

Regards
Gert
--
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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
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/3934ce43-4004-446e-a0fc-616803112ac1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Florian Apolloner
2015-07-27 07:57:41 UTC
Permalink
Doesn't get_inline_instances
(https://github.com/django/django/blob/master/django/contrib/admin/options.py#L520)
do exactly that?

Cheers,
Florian
Post by Gert Steyn
Hi All
I've been using Django since before newforms-admin and have seen
ModelAdmin gradually becoming more customization. I often use dynamic
inlines (based on the state of the object) and would like to clean up the
implementation a bit.
return self.inlines
to ModelAdmin and then change
inline_instances = []
to
inline_instances = []
Any reasons not to do this?
Regards
Gert
--
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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
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/5e862cec-f739-4c44-9898-61a7e4bacd5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Shai Berger
2015-07-27 08:03:34 UTC
Permalink
Post by Florian Apolloner
Doesn't get_inline_instances
(https://github.com/django/django/blob/master/django/contrib/admin/options.
py#L520) do exactly that?
The request, as far as i understand, is to have the list of inline classes be
determined dynamically, using the edited object and the request. You can get
that by overriding get_inline_instances, but you'd have to copy code from the
core in order to get correct handling of permissions.

I think the request makes sense.

Shai.
Gert Steyn
2015-07-27 09:43:59 UTC
Permalink
Duplicating an entire method from core is the easy part, remembering to
check that against the new Django code every time there is a new Django
release is the actual problem.

Gert
--
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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
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/40c1afd4-f150-4016-8679-f0a574a936fa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Florian Apolloner
2015-07-27 13:05:46 UTC
Permalink
I always add all classes and then use get_inline_instances to filter it.
While the request per se makes sense I have the feeling that the admin is
becoming a dumping ground for every possible method out there :/
Post by Florian Apolloner
Post by Florian Apolloner
Doesn't get_inline_instances
(
https://github.com/django/django/blob/master/django/contrib/admin/options.
Post by Florian Apolloner
py#L520) do exactly that?
The request, as far as i understand, is to have the list of inline classes be
determined dynamically, using the edited object and the request. You can get
that by overriding get_inline_instances, but you'd have to copy code from the
core in order to get correct handling of permissions.
I think the request makes sense.
Shai.
--
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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
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/c39477c6-3dcb-483a-8b5c-ca7316119ddb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Gert Steyn
2015-07-27 19:09:28 UTC
Permalink
Post by Florian Apolloner
While the request per se makes sense I have the feeling that the admin is
becoming a dumping ground for every possible method out there :/
We have six views squeezed into a single class, making it customizable will
inevitably require a large number of methods.

My prediction is that it will naturally progress up to the point where
every method found in ListView, CreateView, UpdateView and DeleteView is
now also implemented in ModelAdmin. At that point we'll realize that
everything will be a lot cleaner if we simply redo ModelAdmin as a thin
wrapper around the above mentioned CBVs of which any one can then be easily
substituted by a subclassed version if required... :-)
--
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 django-developers+***@googlegroups.com.
To post to this group, send email to django-***@googlegroups.com.
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/c0cc7cc1-1a47-4bef-b790-a8d8a9e9de96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Continue reading on narkive:
Loading...