potential polymorphic inline admin

[smcoll]

i'm interested in making use of admin inlines for polymorphic models.
i saw some initial discussion about integrating the admin at
https://groups.google.com/group/django-polymorphic/browse_thread/thread/84290fe76c40c12d
but as far as i know, no one's written anything yet.

Here are some thoughts about possible inline solutions. To extend the
example in the original discussion, let's say that the Base class has
an FK to an OtherModel class. i'd like to add an inline formset to
OtherModel's ModelAdmin where i can manage instances of ModelA and
ModelB, primarily because at some point i want to manage the order of
those instances in relation to OtherModel.

Seems to me there are two tasks- 1) having each inlined instance
connected to the appropriate ModelForm, and 2) adding functionality to
the "add item" link so it can be determined whether an instance of
ModelA or ModelB should be created.

We can make an inline using the Base model class, the queryset of
which would most likely return ModelA and ModelB instances for already
created instances, but the ModelForm used in the inline for the Base
class obviously won't reflect the fields unique to ModelA and ModelB.
For this reason, it seems that an inline_formset_factory is not
sufficient to do this. Also, even if we could render each instance's
form somehow, only the "stacked" template will suffice, because the
"tabular" style template can't handle instances with differing fields.

My particular use case allows for another scenario, though. If we can
simply extend the default inline and template for the Base model so
each instance has an "edit" link to the actual instance's model form
(as a popup, probably), then we can still used a "tabular" template
(which is better for ordering instances) by adding an additional
column, and keep most of the admin's inline logic in tact. All we
really need to do is make some sort of hook so the related instance's
edit view can be reached.

That still leaves the second problem, though, where the "add item"
link is insufficient. i suppose this link's behavior could be
overridden so it shows a prompt where ModelA and ModelB are listed,
the user chooses one, and the appropriate edit form shown. This idea
isn't as developed.

Thoughts?

[Bert Constantin]

I only used the admin for rather simple tasks myself and have no
real experience with admin enhancements.

I just did look some more into the possibilities of admin integration
and also at the inline formsets.

It's my impression that it might be possible to get pretty far
by overriding admin templates and admin classes.

I don't however know if it's possible to avoid modifying/enhancing the
admin-code itself. While the documented configuration possibilities
seem somewhat limited, overriding admin class methods might allow
go much further.

The inline-formsets you are interested in of course seem more
complicated
than the more simple "normal" object editing and adding. Perhaps it's
better to look into the implementation of this simpler case first.

> Seems to me there are two tasks- 1) having each inlined instance
> connected to the appropriate ModelForm, and 2) adding functionality to
> the "add item" link so it can be determined whether an instance of
> ModelA or ModelB should be created.

Yes, I also believe that these are basically the only two things
missing
in the vanilla admin in order to make it work fully polymorphically.

Kind Regards
Bert Constantin

On 10 Nov., 23:20, smcoll <smc...@gmail.com> wrote:
> i'm interested in making use of admin inlines for polymorphic models.

> i saw some initial  discussion about integrating the admin athttps://groups.google.com/group/django-polymorphic/browse_thread/thre...

[tictac...@gmail.com]

I have exactly the same problem.
As far as I know, there is no existing way to add different subclasses to the same queryset (a hereMyCoolClass_set which is caused by a Foreignkey) while the order matters. It seems hardly to be good use the "added_date_time" (not only because I would have to change the queryset I'm writing in) or to add an ID manually. So: will this feature which is descriped here come? Or is there some (more or less) easy way to do this (without changing something in the original django package)?
Thank you for reading this,
Asqiir

[mieux...@gmail.com]

I confess I managed to do it a while ago (I'm no longer working on this type of project).

The challenge is that you need to show an inline that varies according to the type of inline model.

The way I addressed it at the time was to have a generic (default) inline with a drop down menu listing the various models available. Then this would make an Ajax call to the server that would return the actual inline for the chosen model (you had to manage the sequence number of the inline, etc.). It took quite a while to fine tune as I had to tweak the model forms, in particular given that the form class in the default model form class (I try to remember, sorry if I'm not precise) was an attribute and had to be tailored to the actual form class of the given inline. So, in my solution, I was generating the form class dynamically.

To let all this happen, the class of the ModelAdmin containing the inlines had to be complemented with a Mixin for the Ajax part.

Then the polymorphic model admin as well.

I must add that I was regularly reaching the limits of my solution here or there, to the point where I adopted another, more WYSIWIG solution : instead of taking it from the ModelAdmin templates and enhancing them with my stuff, I took it from my own page template (showing the inlines the way each of them is supposed to appear on the page) which I complemented with all the necessary Admin-specific stuff to interact with ModelAdmin (see the Admin templates). Each inline would have an "Edit" button calling a Polymorphic Model Admin in an iframe and a bit of JS to let all this interact nicely (page refresh etc.). When you think of it, that's the way e.g. Django CMS deals with its different types of contents.

[mieux...@gmail.com]

sorry, read "the form class in the default model formset class" (corrected below)

Le vendredi 24 février 2017 00:05:07 UTC+1, mieux...@gmail.com a écrit :

I confess I managed to do it a while ago (I'm no longer working on this type of project).

The challenge is that you need to show an inline that varies according to the type of inline model.

The way I addressed it at the time was to have a generic (default) inline with a drop down menu listing the various models available. Then this would make an Ajax call to the server that would return the actual inline for the chosen model (you had to manage the sequence number of the inline, etc.). It took quite a while to fine tune as I had to tweak the model forms, in particular given that the form class in the default model format class (I try to remember, sorry if I'm not precise) was an attribute and had to be tailored to the actual form class of the given inline. So, in my solution, I was generating the form class dynamically.