Having read the various topics about MultiLevelWiki, links to databases, plugins etc. etc. (advanced functionality in general) an idea came to mind which provides a fairly elegant solution for both.

First of all MultiLevel and related stuff - I very much liked the very simple approach from Andrea in WorkFlow. It was in 1999 so here's a copy of the text I meant:

---

I have just tried in my home TWiki installation to create subdirectories inside a TWiki web ... it works!!! for any depth!!!

Suppose you create the directories Codev/WorkFlow/Step1 and Codev/WorkFlow/Step2, you can view/create topics in each one. E.g. you can create Codev/WorkFlow/Step1/DocumentOne.

To look for changes in that web you add a slash at the end, e.g. ...changes/Codev/WorkFlow/Step1/

We just need a way to refer to topics in lower levels ... what if we just allow dotted lists as WorkFlow.Step1.DocumentOne ?

---

Wonder why nobody followed it up (or do I miss something?).

the approach was simply to allow subdirectories within a web which contain subtopics. I.e. not having topics behaving like webs etc., but just topics that can contain subtopics. Instead of Andrea's dots I would prefer using a Unix-path like style for writing them (topic/subtopic/subsubtopic)

This only requires for

1. allow WikiWords separated with /'es to be a valid WikiWord (i.e. MainTopic/SubTopic/SubSubTopic becomes a single hyperlink to that resolves to SubSubTopic)
2. have the topic loading routines translate Topic/SubTopic into /web/data/Topic/SubTopic.txt (does that already?)

Anyway, if we take it one step further and have the topic loader to look for topics in such a way that if MainTopic/SubTopic cannot be found, it starts searching for MainTopic. If this topic exists, then load it, with the original URL available in a variable (in fact - this would be already the case, in the REQUEST_URI env var).

Now this topic could contain special tags for a particular PlugIn that can dynamically generate the requested topic, based on the original request.

E.g.

• by pulling data from a database (e.g. a plug-in that retrieves an employee record when referring to CorporateDatabase/JohnDoe - the plugin specific tags would be included in the topic CorporateDatabase)
• computing it (e.g. calendar plug-in, web/MyCalendar/ThursdayJune22 - results in the MyCalendar topic to be rendered with the calendar plug-in generating the content for the ThursdayJune22 topic)
• whatever you can think of

I think that this would be a usefull extension to the current plugin mechanism, and would be a very simple way to allow all different kind of information sources (and functionality) to integrate neatly with TWiki. (Essentially this is a way to pass parameters to a plugin embedded in a topic, without hardcoding them in the topic containing the plugin tags)

Only problem I see is the fact that those VirtualTopics do not really exist (that's why they're called virtual afterall ... so searching and indexing would required special treatment as you cannot simply browse directories to find them (e.g. a Search API - every virtual topic that is searchable should then implement [that is - the plug in] a specific search funtion which is called by Search instead of accessing the various topics directly).

Things to be done for VirtualTopics:

• define an API for plugins that want to deploy them
• adapt the topic loading function as described
• have/the/subtopic/handling/inplace

Well, shoot me - stupid idea, done already or ...

-- JeroenVanDongen - 20 Jun 2001

I have a different concept of VirtualTopics, as I don't see the need for nested subdirectories to implement them. However, you do need a defining topic that states how the topic will be dynamically generated, and a list of topic names that will utilize that generating method. The implementation of this is somewhat apart from the actual goal, and I imagine subdirectories may be a way to do it.

As an example, consider the following situation. Assume you have defined a web to be a set of book reviews. Each book review will include a form that describes the book title, author, publisher, etc. and then the edit box will be used for the free-form review. The title of the page and some elements are simply the formfields evaluated in the body of the topic so these are not duplicated.

Let's say you have a bunch of books in this Twiki-style database, and you would like to summarize the books written by given authors, as the content of the author's name topic. For example, if JoeBlow was an author, when we access the JoeBlow topic, we would get search results of all the books that Joe Blow had written. The text of all author topics is precisely the same, namely something like this:

---+ %TOPIC%

%SEARCH{"[B]ookForm;%TOPIC%" regex="on" nosearch="on" nototal="on" noheader="on" order="$formfield(BookTitle)" format="   * _[[$topic][$formfield(BookTitle)]]_ by $formfield(BookAuthor) ($formfield(PublishYear))" excludetopic="[B]ookForm|BookTopicTemplate|SubjectCategory|BookReviews|WebPreferences"}%

Now, one way to handle this is to create topic files for each of the authors, or perhaps have a master-topic that would list the topics that can be generated from the same topic text, like that shown above. It would be necessary to know what the topic names are. The savings is that the topic files need not actually exist, making the whole thing run faster, smaller, better.

-- RaymondLutz - 02 Dec 2003