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:
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