tree admin

[Ksenia Marasanova]

Greetings,

Since Django has such a great admin UI, I really wonder what is your
opinion about admin for tree-like structure. It seems the natural way
for modifying site navigation. On the other hand, the most friendly os
(that without doubts was the inspiration source for django admin ;-)
seems to avoid it -- no trees for i-apps, and Finder default view is
not tree-like.
Is the lack of tree-like widget / admin intentional? How do you guys
handle admin for site navigation?

Thanks,
--
Ksenia

[Jacob Kaplan-Moss]

Hey Ksenia --

Generally, we've just used the templates for site navigation; we've
assumed that having good navigation is something so important that it
should be handled by a designer and not a content producer. Still,
that's a tenuous argument at best, and you're totally right that a
hierarchical option for the admin would be quite cool.

We've got some code floating around that does it for one particular
object -- basically a hack for one particular client -- but maybe
something can be adapted for any object... It's a cool idea, anyway.

Jacob

[Ksenia Marasanova]

2005/7/27, Jacob Kaplan-Moss <ja...@jacobian.org>:

> Generally, we've just used the templates for site navigation; we've
> assumed that having good navigation is something so important that it
> should be handled by a designer and not a content producer. Still,
> that's a tenuous argument at best, and you're totally right that a
> hierarchical option for the admin would be quite cool.

Well, this is probably the simplest admin possible -- tree on the left
and wysiwyg editor on the right. Later on some tree "blocks" can be
linked to the navigation on the public site. But you are right, the
content producers are not very good navigation designers :/ I am still
looking for ideal concept of navigation editing in relation with
content. Typo3 has really advanced one, I think: http://www.typo3.com/

>
> We've got some code floating around that does it for one particular
> object -- basically a hack for one particular client -- but maybe
> something can be adapted for any object... It's a cool idea, anyway.

I would love to hear what database design you (or other) use. It's
kind of PITA :-)
I finally decided to use this structure:
id
name
url (slug field :-)
parent_id
(+ other fields...)

When node is added / updated the slug field is re-created. Slug field
in this case contains the whole path up to top, i.e.:
/information/somepage/somesubpage/
When this url is requested, one database SELECT is needed to look up the page.

The biggest issue about UI is rearranging the nodes; I believe that
ideally it should be drag and drop. The closest solution I found is
this one: http://tool-man.org/examples/
It does not allow (yet) dragging between lists. But this one does:
http://neb.net/playground/dragdrop/ The lists are not nested, but I
hope the same script with little tweaks should work for nested lists
too.. I didn't try it yet.

--
Ksenia

[Ronald Jaramillo]

Hi,
Currently I use this widget for all my sites trees:
http://www.destroydrop.com/javascripts/tree/
It's quite simple/small and easy to customize and/or extend.
It could be fun to implement drag&drog / reordering on top of it.
(...and extended properties view, and sortable views and contextual
menus aaand...)
Lately I been thinking about how a column-view widget (like NeXT -
OSX) will work for displaying/administering a site structure (?)

Regarding the database structure, I have settled on a page +
page_objects aproach, where page looks like this:

page
--------------------
id
name
title
parent
position
visible_on_navigation
...other attributes...

I use to do a recursive travelsal of all page records and keep a
cache in a tree object in memory. I query this object when I need to
build the navigation or breadcrumb path.

The page_objects is where you store the actual content

page_object
----------------------
id
name
content_type
text

If you want to reuse your objects across your site you can use a
third table (page_object_to_page) to connect them, otherwise you can
just
store the reference to the parent page in your page_object table.

Using page objects give you more flexibilities regarding layout and
structuring of your documents.
Users can build a page containing n numbers of page_objects, which
can be different kind of media,
free textual context or forms for gathering structured data.

Cheers.
Ronald

[Ksenia Marasanova]

2005/7/27, Ronald Jaramillo <ron...@manoamano.dk>:

>
> Hi,
> Currently I use this widget for all my sites trees:
> http://www.destroydrop.com/javascripts/tree/
> It's quite simple/small and easy to customize and/or extend.

It doesn't have js based add/edit/delete possibilities, does it?

> It could be fun to implement drag&drog / reordering on top of it.
> (...and extended properties view, and sortable views and contextual
> menus aaand...)
> Lately I been thinking about how a column-view widget (like NeXT -
> OSX) will work for displaying/administering a site structure (?)

It would be cool I think. There was something on ALA about it:
http://www.alistapart.com/articles/complexdynamiclists/

>
> Regarding the database structure, I have settled on a page +
> page_objects aproach, where page looks like this:

[...]

Cool, thanks for sharing! I have something similar with "data-widgets"
(like database queries, forms, etc) that can be inserted into wysiwyg
editor. Both approaches have pros and cons I guess..

--
Ksenia