Recursive inlines in admin?

[Jeff Forcier]

Hi folks,

I definitely remember this subject coming up before (possibly as far
back as magic-removal, even) but I'm either misremembering, or not
using the right search terms. Pointers to previous discussions/tickets
would be welcome.

I'm imagining the ability to have recursive inline editing: e.g. in a
simple hierarchy of Model C has FK to Model B has FK to Model A, when
viewing the admin form for Model A, to not only have Model B as an
inline, but to have Model C inlined inside the fieldset for Model B,
allowing you to set up a slice of that entire hierarchy in one go.

First: is this currently possible? It doesn't appear to be, based on
poking around the API for the ModelAdmin hierarchy, nor does it seem
possible to achieve it via forms/formsets (as there's no easy way to
have a single form/formset represent >1 model at a time, AFAICT).

Second: if not possible, is it desirable? I recognize that with any
nontrivial hierarchy/number of extra objects per inline, the visual
representation could become ghastly. But assuming its usage is limited
to semi-trivial scenarios, it seems like the existing admin API could
be very easily extended to support this. I haven't done serious
investigation, but am thinking something like simply allowing/
interpreting the 'inline' attribute on InlineModelAdmin (i.e. making
InlineModelAdmin more closely resemble a subclass of ModelAdmin, which
is probably the logical conclusion of this line of thought).

(Also, I'm a large proponent of the "if the admin doesn't cut it, just
roll your own view/form/template" -- but this feels to me like
something that would be a natural admin feature, and widely
applicable.)

Assuming I'm not missing something obvious, I'd be quite willing to
take a closer look at what would be required to implement this, and
put a patch together at some point if it appears feasible. Just want
to make sure I don't need a reality check first :)

Regards,
Jeff

[Jeff Forcier]

Hi all,

Looks like my below post fell through the cracks; I'm hoping it's
because everyone was busy preparing for DjangoCon, although I wouldn't
blame people for skipping past my wall of text :) Does anyone have an
opinion on recursive inline editing, one way or the other?

Regards,
Jeff

[Cortland Klein]

I'm having the same challenge right now; recursive inlines.

Since I couldn't find an existing ticket for nested or recursive
inlines in admin, I filed #9025.

I'm looking through the code but have not been able to find where I
could actually implement this.

On Sep 9, 2008, at 6:57 AM, Jeff Forcier wrote:

> Looks like my below post fell through the cracks; I'm hoping it's
> because everyone was busy preparing for DjangoCon, although I wouldn't
> blame people for skipping past my wall of text :) Does anyone have an
> opinion on recursive inline editing, one way or the other?

--
Cortland Klein <cort...@apple.com> +1 408 506 9791
Web Developer, Retail Training
Apple Inc.
10101 Bubb Rd.
Cupertino, CA 95014
http://apple.com/retail/

[Joseph Kocherhans]

On Thu, Sep 4, 2008 at 2:08 PM, Jeff Forcier <bitpr...@gmail.com> wrote:
>
> I'm imagining the ability to have recursive inline editing: e.g. in a
> simple hierarchy of Model C has FK to Model B has FK to Model A, when
> viewing the admin form for Model A, to not only have Model B as an
> inline, but to have Model C inlined inside the fieldset for Model B,
> allowing you to set up a slice of that entire hierarchy in one go.
>
> First: is this currently possible? It doesn't appear to be, based on
> poking around the API for the ModelAdmin hierarchy, nor does it seem
> possible to achieve it via forms/formsets (as there's no easy way to
> have a single form/formset represent >1 model at a time, AFAICT).

You're not missing anything. It isn't possible.

> Second: if not possible, is it desirable? I recognize that with any
> nontrivial hierarchy/number of extra objects per inline, the visual
> representation could become ghastly. But assuming its usage is limited
> to semi-trivial scenarios, it seems like the existing admin API could
> be very easily extended to support this. I haven't done serious
> investigation, but am thinking something like simply allowing/
> interpreting the 'inline' attribute on InlineModelAdmin (i.e. making
> InlineModelAdmin more closely resemble a subclass of ModelAdmin, which
> is probably the logical conclusion of this line of thought).

I'm pretty convinced that it isn't appropriate for the admin, but I'm
not convinced that something like that absolutely shouldn't be in
Django. It turns out that recursive inlines are hard. I tried pretty
hard to make it work in the early days of FormSets, but I couldn't get
all of the pieces moving in the right direction at the same time.

That said, I'm pretty stupid, and the fact that I couldn't figure
something out doesn't mean a whole lot. My suggestion to anyone who
wants to try this is to completely start over. Don't use the FormSet
code. It probably won't help you. Also, maybe take a look at
FormEncode. If I remember correctly, it can do such things.

I'd wager that none of the core devs are going to spend any time
implementing it, I certainly won't, but it would work just fine as a
third-party thing, and maybe with enough support could make it into
Django someday.

Joseph

[Justin Fagnani]

I'm currently working on recursive inline editing using formsets, but
not in the admin. It's not completely working yet, but it's pretty
close. I've had to fix a number of things in formsets, and my patch
for that is in #8160. I got side tracked from that project for a
while, but I'll be back to it next week.

Cheers,
Justin

[Adrian Holovaty]

On Thu, Sep 4, 2008 at 4:08 PM, Jeff Forcier <bitpr...@gmail.com> wrote:
> Second: if not possible, is it desirable? I recognize that with any
> nontrivial hierarchy/number of extra objects per inline, the visual
> representation could become ghastly. But assuming its usage is limited
> to semi-trivial scenarios, it seems like the existing admin API could
> be very easily extended to support this.

This has come up a number of times over the years, and I still haven't
wrapped my head around why somebody would need this functionality...
Surely one could just use the "standard" admin for the third-level
objects, then use two-level inlines for the first- and second-level
objects?

Adrian

--
Adrian Holovaty
holovaty.com | everyblock.com | djangoproject.com

[Jeff Forcier]

Thanks, everyone, for your replies! Doing a reply-to-all thing here...

On Sep 10, 9:27 pm, "Adrian Holovaty" <holov...@gmail.com> wrote:
> This has come up a number of times over the years, and I still haven't
> wrapped my head around why somebody would need this functionality...
> Surely one could just use the "standard" admin for the third-level
> objects, then use two-level inlines for the first- and second-level
> objects?

It's not so much as a "need" as a "nice to have". I currently do what
I think you describe, given A has many Bs has many Cs -- class A has
class B as an inline, and when I am done with those two, I navigate to
the admin section for class C, select the class B I just created in
the ForeignKey dropdown, and create that third object. This obviously
works, but it gets pretty tedious when doing lots of data entry,
especially when I have multiple B/C groupings per instance of A.

Although, now that I think on it, perhaps I have it backwards, and
you're saying to use a regular no-inlines form for class A, then do a
series of save-and-edit-new for a B+C edit-inline relationship? That
would actually make a bit more sense...

On Sep 10, 7:19 pm, "Joseph Kocherhans" <jkocherh...@gmail.com> wrote:
> It turns out that recursive inlines are hard. [...]

Thanks, I was expecting someone had taken a stab at it, but hadn't run
across any mentions.

> That said, I'm pretty stupid, and the fact that I couldn't figure
> something out doesn't mean a whole lot. My suggestion to anyone who
> wants to try this is to completely start over. Don't use the FormSet
> code. It probably won't help you. Also, maybe take a look at
> FormEncode. If I remember correctly, it can do such things.

And here I thought *I* was modest :) Thanks for this also, advice
noted.

> I'd wager that none of the core devs are going to spend any time
> implementing it

Oh, certainly! That was never my intent; I'd hate to be That Guy
standing up and going "please implement feature X for me, I need it
right now, chop chop!". Just wanted to get a sense of whether I was on
the right track or totally out in left field.

On Sep 10, 7:38 pm, "Justin Fagnani" <justin.fagn...@gmail.com> wrote:
> I'm currently working on recursive inline editing using formsets, but

> not in the admin. [...] my patch

> for that is in #8160.

Thanks for the note, and good luck! Ironic that you're taking this
approach given Joseph's advice above, but you sound like you're making
progress -- I'll check out your patch.

On Sep 10, 6:52 pm, Cortland Klein <cortl...@apple.com> wrote:
> Since I couldn't find an existing ticket for nested or recursive
> inlines in admin, I filed #9025.

And thanks for opening that ticket; although given what Joseph said
above, I'm not sure if it will stay open, or if it would be considered
a partial duplicate of Justin's #8160.


I can't write a short email, can I? :) Thanks again, all, for the
discussion. For now I think I may try re-jiggering my existing edit-
inline setup and see if that helps my data entry speed, and I'll
definitely watch #8160/#9025 with interest -- I think this is still a
noble goal. May pitch in as well if I have time, of course.

Regards,
Jeff

[F.Ingra...@gmail.com]

On Sep 11, 2:27 am, "Adrian Holovaty" <holov...@gmail.com> wrote:

> On Thu, Sep 4, 2008 at 4:08 PM, Jeff Forcier <bitprop...@gmail.com> wrote:
> > Second: if not possible, is it desirable? I recognize that with any
> > nontrivial hierarchy/number of extra objects per inline, the visual
> > representation could become ghastly. But assuming its usage is limited
> > to semi-trivial scenarios, it seems like the existing admin API could
> > be very easily extended to support this.
>
> This has come up a number of times over the years, and I still haven't
> wrapped my head around why somebody would need this functionality...
> Surely one could just use the "standard" admin for the third-level
> objects, then use two-level inlines for the first- and second-level
> objects?

I'll give you my use case for this: currently we use the admin
application to generate reports. Each report has a number of findings,
which are implemented as an inline. Several users have found that they
need to split the findings across several sections, which at the
moment requires Word table wrangling. It would be great if I could
have a simple FindingsSet model which would be a section heading plus
the relation to the findings. The best UI for this would be the curent
inline view but with the editable section heading above (and another
set of findings below). Given that the majority of reports will only
have a single section, however, making users edit the findings on a
different page would be less than ideal.

This isn't a 'so implement it now' email, it's just that this is what
I'd use it for. As it is I'll probably just add a 'group ID' field to
the Findings model, which will achieve pretty much the same thing. And
that will make the hand editing of OpenXML I'll have to do slightly
less painful as well.

I hope that makes sense; a bit more 'real world' than A-B-C examples.

Regards,

Felix

[DoctorMO]

I'll add my two cents in line...

I've been wrangling with similar problems for developing some workflow
classes that allow the assembly of class hierarchies with ModelForms
into a coherent set of steps to insert data.

> It turns out that recursive inlines are hard. [...]

I concur, From what I gather just the in line models alone can cause
deep recursion if there are not limits placed on how many depths you
allow. Some models have circular foreign keys.

> > > Second: if not possible, is it desirable? I recognize that with any
> > > nontrivial hierarchy/number of extra objects per inline, the visual
> > > representation could become ghastly. But assuming its usage is limited
> > > to semi-trivial scenarios, it seems like the existing admin API could
> > > be very easily extended to support this.

Well however it's organised on the screen, we currently have one depth
of in-line and popup window creation (with dropdown target); We don't
have multiple field discovery (each field limiting the next until you
get an existing record or create a new one); We can't do multiple
steps in our admin pages no matter how complex the models (without
customisation obviously); and some of the widgets could do with more
ajax support to make things more application like.

> > This has come up a number of times over the years, and I still haven't
> > wrapped my head around why somebody would need this functionality...
> > Surely one could just use the "standard" admin for the third-level
> > objects, then use two-level inlines for the first- and second-level
> > objects?

Well I've seen far more normalised models that don't match how simple
data entry people's minds expect the forms to be presented. Binding
them back together using in-lines is one method of having a complex
set of models editable as one entry form.

Regards, Martin

[James Smagala]

Hey All,

First off, I am a relatively new Django user, and certainly not a
developer at this point, and most of this post is pure speculation.
With that disclaimer, I'll share my situation and opinion:

From DoctorMO:

> Well I've seen far more normalised models that don't match how simple
> data entry people's minds expect the forms to be presented. Binding
> them back together using in-lines is one method of having a complex
> set of models editable as one entry form.

This is exactly the problem that I am running into right at the
moment. My data entry people will pitch a fit if I make them use the
current setup, which would require at least two levels for my site,
with very awkward transitions (save this object, go add a related
object, search for the first object using a raw id lookup, then
finally edit the related inlines). This is painful. But...

From Adrian:

> This has come up a number of times over the years, and I still haven't
> wrapped my head around why somebody would need this functionality...
> Surely one could just use the "standard" admin for the third-level
> objects, then use two-level inlines for the first- and second-level
> objects?

I started writing a long email about why I want this functionality,
then changed my mind. Adrian's 'just use the standard admin' response
would get me *very* close to what I want, with just a few
enhancements. Here's how:

I just watched to 'I want a pony' session from DjangoCon, and I
noticed two points that fit this discussion:

1. Raw ids are 'too raw'. Let's do some sort of search/select instead
of a drop down.

2. Databrowse is cool, but outdated. Databrowse integrated into Admin
would kick ass.

I'll add one more:

3. With the Admin refactor, it should be easy to create *both* an
inline *and* a stand-alone admin object for the same model, and
register both.

I'm assuming you have a layout something like this (a simplified look
at my database layout):

A <-- B <-- [X, Y, Z]

A is your main table, B has a few entries for each A, and X, Y and Z
all point B. I *think* this will generalize pretty nicely, but I
haven't thought my way through any really complicated relations yet.

---

My proposal is this. The cool thing databrowse does is link between
related objects. To get databrowse-like functionality with only a
little work, do this:

1. Implement an option to search/select in place of raw ids or drop-
down/select on the stand-alone admin.

While I'm not much of a UI guy, it seems to me that I can already have
most of the search functionality I need set up in the Admin site for
my related object. So, keep the raw id idea, but display a string
representation of the object instead of its id?

2. Create an Admin object for A, and inline B. Also create a stand-
alone Admin object for B, and inline X, Y and Z.

3. If both inline and stand-alone Admin objects are registered for B,
add links from one to the other.

Text links would be fine, or a small go-to-this-object-arrow icon.

3a. If you don't register both admin objects, the link could instead
go to a typical databrowse page to let you look at the related object,
and what objects are related to it.

This is not critical for this discussion, but it does seem to be an
easy way to start integrating databrowse functionality into the admin.

---

Now my workflow looks like this: Add an A, and add a B inline, save.
Now link to my newly created B, and edit X, Y and Z objects inline,
and save. And if I'm creating a B in the stand-alone admin, I can
easily search for my related A, then navigate to that related object
by clicking a link. This is the visual equivalent of the way that
Django's query API works.

This would mean I could train my users to save the first object, then
follow a link. That's a pretty easy thing to do, and it is
significantly less painful than the first workflow I described using
the current admin setup.

How hard would this actually be to accomplish? Are there any glaring
errors in my thinking? Complex relationships that hose the whole
idea?

James