Version 12 of Wiki hierarchical table of contents

Updated 2006-06-24 05:12:25

The zwiki implementation of wiki has a nice structuring feature (see the discussion of this feature at the zwiki site [L1 ] ([L2 ] doesn't work) and an example at the Zope site [L3 ]). This structuring feature allows parent and child relationships to be modified on the backlinks page. Each reference to a page are listed with checkboxes. A checked checkbox indicates the page is actually a parent. The page from which another page is created is by default a parent. This default can be overridden by toggling the checkboxes on the backlinks page

Here is a simple version of this concept for Wikit where all the references to a page treated as a parent and the parentage cannot be changed. The following code uses the graph struct from tcllib:

 # Returns a graph containing the wiki page ids as nodes with
 # arcs connecting parent nodes to child nodes
 proc wikiRefsToGraph {} {
    set graph [graph]

    # Add each nonempty page to the graph (empty pages have date of 0)
    foreach pageId [mk::select doc.pages -min date 1] {
       if {![$graph node exists $pageId]} {
           $graph node insert $pageId
           }
       set refs [mk::get doc.pages!$pageId refs]
       foreach ref $refs {
           if {![$graph node exists $ref]} {
               $graph node insert $ref
               }
           $graph arc insert $ref $pageId
           }
       }
    return $graph
    }

 # Returns an html tree form of the given graph beginning with 
 # the optionally given node id as the root.  A node's children
 # are only displayed the first time the node is encountered.
 # After that "..." is appended to the node name
 proc getHtmlTreeFromGraph {graph {node 0}} {
    global visitedNodes
    puts -nonewline "<li>[Wiki - $node.html]"
    if {[lsearch $visitedNodes $node] < 0} {
       if {[$graph node degree -out $node] > 0} {
            puts <ul>
            }
        puts ""
        lappend visitedNodes $node
        foreach child [$graph nodes -out $node] {
            getHtmlTreeFromGraph $graph $child
            }
       if {[$graph node degree -out $node] > 0} {
            puts </ul>
            }
       } elseif {[$graph node degree -out $node] > 0} {
       puts "..."
       } else {
       puts ""
       }
    }

Here is an example use of this code:

 package require graph
 namespace import ::struct::graph::*
 set visitedNodes ""
 getHtmlTreeFromGraph [wikiRefsToGraph]

RA2 I agree with you 200%, Brian. ZWiki is in my view the best wiki of them all, for it creates hierarchical contents we are all used to. Without a hierarchy of some kind, a wiki ends up being well.. let's not be afraid of words...: a mess.

Zwiki is a more or less a wiki outliner.

I never thought the backlinks concept (invented by Stan Silver at C2.com) was a hot invention. Of course the backlinks concept is far-out when there is nothing else around! It is better than nothing so we settle for it, the same way we'd settle for an ugly girl until a gorgeous one shows up. All in all, outlines make much more sense! And this is what Zwiki does: it is a wiki outline.

I believe that when an information is structured, it adds value to itself. To the opposite, when an information is not structured, it is worthless. In this regard, your tkoutline is marvellous because it is very structured!

I'd love to try your code if only it could be inserted in a script of some kind.


RA2 I have a good idea for you. Take tkoutline, modify the code and make it a wiki. And you'll have a winner. If you need details, put the questions on my homepage and I'll explain! Robert Abitbol


DDG May be my nwikit clone would be a good choice although it currently only makes simple hierarchies (all wiki links on the home page wich are in a list are used). Adding one level more would be an easy task. See: http://goblet.molgen.mpg.de/nwikit

Robert Abitbol Very interesting, Detlev!

It would be interesting if you could have a look at Zope Wiki in action somewhere. You enter a site, you have a quick look at the outline and right away you know what the site is about, you see the articulations, the structure.

I was very interested in wiki's hierarchical table of contents and I have studied Wiki's hierarchies inside out and outside in for a long time a few years ago. To my knowledge, there are four types of hierarchies in all wikis:

* The Zope outline (well described by Brian above)

* The slash concept in Usemod; when you create a link with a /, the page where the link is created becomes the father link and the pages created its children. Ex: In a page called Animals, you create a new link: /Ostriches. Another page: /Lions. Your pages will be shown this way in Recent changes. Animals/Ostriches; Animals/Lions. Very useful feature!

* The father/child concept in Yet Another wiki; pretty complex

* Dave Parker's strange concept of compound words: AnimalsBirdOstriches will make the 2 links (Animals and Birds) appear on top of the Ostriches page. Not a bad idea! I was suggesting something else to Dave and this is what he understood! Great concepts have been invented this way, through misinterpretations! :-)

* The Austrian's guy (I forgot his name) concept of key pages. Links are written on a key page. Ex: A key page called Animals would contain the Ostrich, Lion, etc. links. He has a list of key pages. I'll try to get the address of his wiki.

I don't consider the Category System (invented at C2.com) a hierarchical table of contents. It is a sort of indication at the bottom of a card indicating where the card belongs.

Of course no one minds the lack of hierarchy in wikis (since we all more or less spend our time peeping Recent Changes) but for serious contents, one needs an outline, a structure.

If you could put your wiki online, we could test the hierarchy.

DDG http://goblet.molgen.mpg.de/cgi-bin/wiki/public/eurotcl2006-test.cgi/0 you can edit this to test the outline. Currently nested outlines are missing but they should be easy to implement. Please read the nwikit-article for the supported markup as well. I would see, with an true hierarchical outline a wiki becomes a true website.

CMcC thinks there's just one small problem with this: a Wiki is a directed graph of pages, and general digraphs aren't hierarchies. Of course, you can always put a spanning tree over a digraph by deleting some links (ie: destroying information.) In view of the nature of destroying information on a Wiki in order to make it more navigable, I would like to suggest a name for the links so formed: goosesteps.

Robert Abitbol Digraph? What is that?

Colin, a real manageable content management systems is not made of hundreds and hundreds of independent pages linked together with a vague category system; to the contrary, it is made of pages linked together in a hierarchical structure called an outline.

Say what you will about the non-necessity of outlines, but I can tell you from my own experience that organization is key. Disorganized people end up being complete failures and their projects end up in the garbage. I have yet to see one successful (and happy) disorganized person.

I have always thought that wikis are in fact collections of simple electronic index cards. It works that way; the system fits the purpose. Surely! But I fail to see how 10, 20 writers writing a book together could produce some serious working this way with a wiki.

Outlines are a great tool used by serious writers.

Dieter, I'll be testing your outline wiki in a second. I have. Indeed the outline could simply be put on Home page or on start page; all links would have to stem from that page et voila! There is your outline!

A nice possible enhancement: start page occupies the left of the screen. We click on a file and it appears on the right of the screen.

No need to create an outline automatically. We could simply type in the numbers: 1, 2 and the letters a), b) etc.


[Category Wikit|Category Package]