Inspiration

The ability to view multilevel trees starting at a specific topic.

Grouping by field (SearchByFields) is too flat. Making multiple webs is too much work and too strict (see for example Wiki:ParallelInheritanceHierarchies). This is not a slight on MultiLevelWikiWebs, I just think there's a need for intraweb hierarchical grouping - little, user-organizing tree chunks - and since topics have parents this is probably not too hard to implement (and complements HierarchicalNavigation).

Sample uses

• View a deep outline.
• View all all trees and discover hierarchical groups that you may have not known existed.

Implementation

What I see is just a type of METASEARCH where not only are a topic's direct children displayed but their children & their children's children, etc in turn.

This shouldn't be too tough. Slurp the topics and their parents into a hash, then using some Tree/Node package (gotta be around), link up children to parents bidirectionally, the rest is formatting through tree walking.

Oh yeah, I guess I should mention I put a "create child topic" on many topics so that users have the ability to branch off the current discussion (this works well with a "see my children" search on the same page). It is mostly a macro (nothing you couldn't do with HTML/regular TWiki commands), but it's compact and makes for a cleaner edit box, so I should package that up for others to use as well at some point. (The part that's not mostly a macro is the ability to inherit FORM data from the parent.)

Any thoughts? I'll look into implementing at some point.

-- SlavaKozlov - 08 Feb 2002

Ok, I did a little research. It seems that the function that actually grabs the correct files of a search, TWiki::Search::searchWeb, is pretty finely intertwined with the formatting of the data. Which isn't so bad usually as it uses a template for formatting, but is a little bit of a problem here because an underlying assumption is that the search results are in a flat array (ie, to produce a table or bulleted list) not something more structured like a tree.

I guess one possibility to explore is whether it's possible to make a search template which makes SEARCH calls in its own turn (thus recursively satisfying my needs). Can't imagine that's too performance optimized, but better a slow version than no version...

-- SlavaKozlov - 08 Feb 2002

Slava,

Sounds good to me. Maybe you want to skim this page: DataStorageForMultiLevelWikiWebs. I think there are a lot of people all wishing for some better ways to handle certain things, like searching and a tree structure type thingie, and thus there is more than one idea about how to accomplish each of them. We have the beginnings of two ways already (webs and parent - child relationships). I'm afraid if we have too many approaches, it will result in too much confusion for the average user and "twiki sysop". (And I am not smart enough and have not tried to put in enough time / thought to evaluate which is best.)

I don't want to discourage you at all, but I am hoping we eventually evolve to a single approach. Maybe we have to go through a "dark age" where many of these approaches are partially (or completely) implemented before we recognize which are most effective and prune some of the others.

Maybe this is a case where two approaches are appropriate -- one approach dealing at the TWiki wide level, and your approach within a single web.

-- RandyKramer - 09 Feb 2002

Hello, Randy thanks for your feedback. I guess I should expand upon on what I meant.

More Inspiration

My core motivation is:

Since humans are able to group data into and make efficacious use of, hierarchies (though with limits), a KB system should allow them to navigate the knowledge base in this way as well.

A couple things - note the soft tone of the requirement - it doesn't imply all the data must be organized into hierarchies; nor that there is a single canonical hierarchy, and that this is but one mechanism - one of diverse ways - to view the data (hence the name, "Tree View").

Other issues - data storage, access control, syntax and even performance - are system requirements, not user ones. They are very much important but not the impetus behind the feature.

I am being neutral as far ideology (at least I think so), I'm not advocating Wiki:SingleSpace nor a complete Death of the Filesystem nor Lifestreams, just avoidance of these restrictions:

• strict classification
• organization relegated to management

This leads to a second requirement:

Give users the ability to organize trees on their own. Thus the Wiki will remain self-organizing and will not require a GodEditor to manage its structure nor a MasterPlan of what the structure of the data is a priori.

(There is nothing to prevent a user from doing this now, which is a feature I would like to keep and to make easier and more powerful.)

I looked around the current TWiki release and released that it was not incompatible with these usability requirements since it already sometimes attached a parent to children (though this was soft: not all topics have parents, and whether this happens seems to be at the discretion of the skin-writer).

The current release also has two hierarchical viewing features:

• The capability to view the list of children for a particular topic (METASEARCH with parent attribute)
• The capability to view the ancestry of a particular topic (HierarchicalNavigation & NavigationByTopicContext).

I wanted to expand these with:

• the capability to view down a topic tree more than one level
• a couple macros to make organizing trees easier (creating a child promoting branches, demoting branches)

Notes:

Creating or navigating multiple overlapping hierarchies needs much more discussion before being considered for implementation.

I just realized one curious side effect of implementing MultiWikiWebs by file structure and using a TreeView style of searching is that it would be possible - though only through some work on the user's/skin-writer's part - to have dual hierarchies: one on the file system, one based on the parent-child relationship.

More Implementation

This exposition is illuminating - but it is nice to have something tangible as well. So...

Despite my outline above, I first attempted a recursive search approach. Something akin to,

%METASEARCH{parent="ATopic" format="%METASEARCH{parent="%CHILD%" format="..."}%"}%

(not real syntax)

but obviously done with a different tag. It worked fine for a couple levels down but, even on my small web, was beginning to get slow and ran into some icky perl problems (probably heap or filehandle overruns). I don't think searchWeb was optimized to be called dozens of times.

My second attempt was the one outlined in the first implementation section above. Grab the topics and their parents, compose a real data tree in memory. Walk the appropriate branch of the tree while formatting. This isn't perfectly optimal either as each file gets read twice (once in searchWeb, but that meta info is lost) and once again in the custom tag handler to get the parent), but it may prove sufficient - my web of 8 levels and 150+ topics clocks in with these numbers:

• 9/100th a second for minimal TWiki topic
• 26/100th of a second for a WebTopics list of all topics
• 65/100th of a second for a TreeView formatted list of all topics (no future features, not optimized)

Interface

I am not completely certain about the interface (is this the stage where I create a Plugin Dev Topic?), provisionally, this much is currently implemented:

%TREESEARCH{topic="topic", form="form", stoplevel="level", web="web"}

topic

the topic from which to view branches

form

all nodes must of be this form/type

stoplevel

how many levels deep to show the tree

web

which web(s) to search

Adding support for the %SEARCH% formatting variables ($isodate, $wikiusername, etc) is pretty trivial but performance impacting. But is it needed?

The Plugin would also have tags/actions for:

• creating children (already implemented)
• promoting branches up a level
• demoting branches down a level

Ok, so is this interesting enough to others for me to actually work it into a full Plugin (all the code's already in a plugin)?

-- SlavaKozlov - 11 Feb 2002

I'm interested. We're using TWiki to capture requirements for a project and the number one complaint is the lack of a hierarchical view. Something like your TRESEARCH would just about cover it.

Given the choice between the additional formatting (isodate, etc.) and speed, I'll take speed.

-- DaveAlsup - 11 Feb 2002

I have implemented threading of topics using extensions to the standard SEARCH variable using plugins. Currently however because SEARCH does not allow you to sort by a metafield it uses the topicname for threading info. This limit's the thread depth to approximately 15-16 levels (and makes the topic name rather horid).

%SEARCH{ "TOPICPARENT.*name=\"(%TOPIC%|%TOPIC%-.*)\";FORM.*name=\"BoardResponseForm\"" web="Home" casesensitive="off" regex="on" nosearch="on" nototal="on" format="$depth(thread=\"$topic\" padding=\"--\") $formfield(Subject)"}%

It does however work as is extremely well. If you could sort by PARENT or METAFIELD it would be a fairly complete system.

See SortSearchByMetaField and EvEm.

-- AdrianLynch - 11 Feb 2002

Despite the fact I'm using an unofficial TWiki Plugin function, searchWeb (using not changing!), I am going to make this into a Plugin. I was asked for a hierarchical bookview, so I put that together. See TreePluginDev...

-- SlavaKozlov - 14 Feb 2002

Made the plugin: See TreePluginDev...

-- SlavaKozlov - 14 Feb 2002