Admin three levels deep

[tim....@gmail.com]

Hi there,

I'm very new to Django and I'm learning it by adapting the stuff from
the tutorial to a new (test) application, a Forum. The tutorial nicely
explains that you don't want "Polls" and "Choices" in the main menu,
because "Choices" is a part of "Poll". With my test-app I want to go
even further. I have a Forum, which has Threads, which have Posts.

For starters, I want all of those to be accesible from the admin menu
(page 2 of the tutorial), so I made my model as so:

class Forum(meta.Model):
[...]
class META:
admin = meta.Admin()

class Thread(meta.Model):
forum = meta.ForeignKey(Forum, edit_inline=meta.STACKED)
[...]

class Post(meta.Model):
thread = meta.ForeignKey(Thread, edit_inline=meta.STACKED)
[...]

This doesn't work as intended, though. It only allows me to make new
Threads, but I can't see/edit/create Posts. Any thought on how to
tackle this? Thanks in advance!

--
Kind regards,
Tim Stoop

[Robert Wittams]

Inline editing is currently designed purely as a two level thing.
This won't be fixed in trunk before it is fixed in the new-admin branch;
I am specifically looking to allow this though, so stay tuned.
There is no schedule for when this feature will be available in trunk.

Also, be aware that this could end up

a) With a very confusing UI
b) POST-ing ridiculous amounts of data.

Which may not be in your users best interests. My aim in enabling this
feature is not really to encourage arbitrary level admins, but to allow
them in the rare case they do make sense - and it is mainly intended for
people using manipulators outside the admin.

Rob

[Tim Stoop]

On 10/7/05, Robert Wittams <rob...@wittams.com> wrote:
> a) With a very confusing UI
> b) POST-ing ridiculous amounts of data.
>
> Which may not be in your users best interests. My aim in enabling this
> feature is not really to encourage arbitrary level admins, but to allow
> them in the rare case they do make sense - and it is mainly intended for
> people using manipulators outside the admin.

Hm, I don't know how you're implementing it (maybe I'll switch to the
new-admin trunk tomorrow, just to take a look), but I think you can
implement it fairly simply without the problems you describe above.

Taking my example, I select "Forum" from the main menu. I get the
Forum props and inline the Threads. Now, when I make a thread, it
stays a textfield, which would be correct if I had just a two level
setup (easy maintenance), but how about making "Thread" a link that
links to a page with the properties of Threads and the assorted Posts
that belong to it, just like it does now in the two level setup. You
could make endless links, like so:

First page:
Object1 properties (changable)
Object2 links -> page 2
Object2 "create new" input fields
Second page
Object2 properties (changable)
Object3 links -> page 3
Object3 "create new" input fields
[...]
Last page
Object(N-1) properties (changable)
ObjectN properties (changable)

That would be logical and sensible, I think.

Just my 2 eurocents :) Feel free to ignore me if I'm talking nonsense :)

--
Gegroet,
Tim

[Robert Wittams]

> >
> Hm, I don't know how you're implementing it (maybe I'll switch to the
> new-admin trunk tomorrow, just to take a look), but I think you can
> implement it fairly simply without the problems you describe above.

Well, it is not implemented fully yet. The main changes for this will be
in django/core/meta/__init__.py in manipulator_save, basically making
manipulators recursive. (Ie child manipulators are instantiated for
inline objects).

> Taking my example, I select "Forum" from the main menu. I get the
> Forum props and inline the Threads. Now, when I make a thread, it
> stays a textfield, which would be correct if I had just a two level
> setup (easy maintenance), but how about making "Thread" a link that
> links to a page with the properties of Threads and the assorted Posts
> that belong to it, just like it does now in the two level setup. You
> could make endless links, like so:
>
> First page:
> Object1 properties (changable)
> Object2 links -> page 2
> Object2 "create new" input fields
> Second page
> Object2 properties (changable)
> Object3 links -> page 3
> Object3 "create new" input fields
> [...]
> Last page
> Object(N-1) properties (changable)
> ObjectN properties (changable)
>
> That would be logical and sensible, I think.
>
> Just my 2 eurocents :) Feel free to ignore me if I'm talking nonsense :)

Yes, this would be one way to present things. This is not currently
implemented in the admin as a built-in inline editing mode.

You could implement it using the edit_inline="path/to/template"
functionality in the new-admin branch, but the tags, objects in context
etc you would need to use are currently undocumented and subject to
extensive change. One issue would be that the manipulator would expect
the fields of all the inline objects to be posted, but they wouldn't be
on the page. Not sure what the best solution is here yet, as this is
dissimilar to the current situations.

Also, be aware that you could make your own entirely custom views that
override areas of the admin if you like. Just hook them into the admin
urlconf.

Robert

[Tim Stoop]

On 10/7/05, Robert Wittams <rob...@wittams.com> wrote:

> Also, be aware that you could make your own entirely custom views that
> override areas of the admin if you like. Just hook them into the admin
> urlconf.

True, but that would be undesirable for me. You'll eventually get all
kinds of update issues and the like. I'll make do with the two level
admin for the moment, it's not a bug problem. I was just wondering if
it was implemented :) Thanks for the help.

--
Gegroet,
Tim

[Adrian Holovaty]

On 10/6/05, tim....@gmail.com <tim....@gmail.com> wrote:
> I'm very new to Django and I'm learning it by adapting the stuff from
> the tutorial to a new (test) application, a Forum. The tutorial nicely
> explains that you don't want "Polls" and "Choices" in the main menu,
> because "Choices" is a part of "Poll". With my test-app I want to go
> even further. I have a Forum, which has Threads, which have Posts.

Hey Tim,

An easy solution would be to give each model -- Forum, Thread and Post
-- its own meta.Admin().

Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org