Dynamic inlines for Django ModelAdmin

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

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

[Florian Apolloner]

Doesn't get_inline_instances (https://github.com/django/django/blob/master/django/contrib/admin/options.py#L520) do exactly that?

Cheers,
Florian

[Shai Berger]

On Monday 27 July 2015 10:57:41 Florian Apolloner wrote:
> 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]

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

[Florian Apolloner]

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 :/

[Gert Steyn]

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... :-)