Twiki's approach of making TWiki webs "visible" to each other is outstanding. It helps people to place their TWiki pages into the right "buckets" at a higher level than categorization. It keeps un-related pages from "cluttering each other up" when looking at indexes, recent changes, et cetera.

However, consider the case of a large number of small groups of people, where each small group would get its own Twiki web. In this case, making the entire list of Twiki webs visible to all other TWiki webs would be a "bad thing".

I'm attempting to revive, cross-reference, and reorganize the discussion of this TWiki usage pattern as LotsOfSmallWebs. A lot of discussion appears below, but it's difficult for someone new to it (like me) to determine the current status of the ideas and mechanisms discussed. Would someone please summarize TWiki's current capabilities and future directions for managing LotsOfSmallWebs? -- MitchellModel - 05 Oct 2002

Some "top level" webs would always be visible, while hundreds of nested webs might only become visible when the user navigates to the "parent" for them. Of course, they're always navigable for a user that knows their destination URL; this is simply a matter of what webs are presented in headers, lists, et cetera.

I know a tree of Twiki webs is probably a lot more complicated to manage than a flat list, but it's important if a TWiki is to handle a large number of only semi-inter-related groups of people.

I'm interested both in approaches to manage this within the existing TWiki structure and in approaches for extending TWiki to manage webs as a tree or a graph.

Thoughts?

-- PaulReiber - 04 Aug 2000

Already possible to something like this in the Alpha version of TWiki.

See the WIKIWEBLIST variable at

• http://twiki.sourceforge.net/cgi-bin/a/bin/view/TWiki/TWikiPreferences
• http://twiki.sourceforge.net/cgi-bin/a/bin/view/TWiki/WebPreferences

It can be set on a Wiki, Web and User basis.

Combined with SubWebs this is probably all you need.

-- NicholasLee - 04 Aug 2000

I do this already with the current version of Twiki. I use a directory notation for the subwebs. If the top level web is Technology the sub web would be named Technology/GPS. You just need to copy the data part of you web in a directory named GPS under Technology.

I also have created some new variables in the WebPreferences page to accomidate which TWikiWebsTable to use. This can be hard coded on your WebHome page when you include it. I use a variable so it is not hard coded, but that requires a change I made to wiki.pm to process variables inside include statements correctly.

I am finishing up some changes to the CreateWeb admin tool that I posted to be more Twiki compliant. Should have that up very soon under ScriptToCreateNewWeb. This script will make it very easy to create your HierarchicallyNestedTwikiWebs. The changes to wiki.pm that I talked about can be found at BetterTWikiTagTemplateProcessing.

-- HaroldGottschalk - 05 Aug 2000

We've implemented HierarchicalNavigation (with cross-reference as described in MultiLevelWikiWebs). It works quite well for our group.

-- StanleyKnutson - 24 Apr 2001

I've implemented HierarchicalNavigation and HierarchicallyNestedTwikiWebs with inherited preferences and management tools (via forms) in MegaTWiki, if anyone's interested. It required minor changes to the core code and templates. I'd be happy to roll it into the existing codebase if there are enough aye's after more discussion.

-- PeterNixon - 25 Jun 2002

I read several aye's and no no's above. I agree with the 'ayes'. CoreTeam - do you have any objection to this becoming a standard feature in TWiki?

-- MartinCleaver - 27 Jun 2002

CoreTeam - given that we have an implementation of this feature in PeterNixons' MegaTWiki, I am interested to hear whether you have concerns about it. Once you have read this topic, can you please fill in the table below?

Others, if you have time to comment, please add yourselves to the table above

If there are specific issues, can you add them to the table below for Peter N and others to comment on? Thanks.

-- MartinCleaver - 05 Jul 2002

Martin- By "web selection mechanism", are you referring to navigation elements (navbar), or selection of webs where forms are concerned?

-- PeterNixon - 08 Jul 2002

Sorry, these are JohnTalintyre's concerns, not mine (see http://twiki.org/cgi-bin/view/Codev/MegaTWiki?rev=r1.15). I transcribed them from his text into the table then lost the history when I moved the table. I've thus added a new column to the table.

-- MartinCleaver - 09 Jul 2002

With regard to the alternate syntax of Thisweb/Thatweb/Subweb, I think this should be made to not work else it will encourage people to write links in a way that can cause problems for the future.

-- MartinCleaver - 09 Jul 2002

If we do disallow "/", it will also require us to disallow the use of the %WEB% variable in wiki notation (in specific links, and in wiki links). Currently, it uses "/" as a delimiter, and is currently used to construct URL's, wiki links, and specific links by plugins, templates, code, and topic text. It would break a lot of templates and code in TWiki at the moment if we disallowed "/". I'm just thinking of backward compatibility issues and migration paths.

-- PeterNixon - 09 Jul 2002

Hmm. How irritating. That's the sort of problem we get when things are not fixed at the beginning. I suppose we could have some sort of high-level fudge to sort it out.

I wonder:

1. what's the advantage of each syntax
2. whether a utility to upgrade the topics in a web would solve the problem.

What do you reckon?

-- MartinCleaver - 10 Jul 2002

Sorry I took so long to respond; Work hollers in myne eers.

I'm generally averse to upgrade utilities; they may unwhittingly break something that was meant to behave a certain way to begin with, and there's the chance that the admin isn't awake enough to back up his stuff before the upgrade (admittedly, me, on some days, esp. on Monday).

As far as syntax goes, I'd like to shadow support the "/", and documentedly support the "." wiki notation as the recommended way of making wiki links in topic text. By shadow support, I mean only support "/" in URL's or specific links (e.g [[][]]) via the Codev variable where it crops up the topic text (this is how I'm currently support it). General usage in topic text via the standard wiki linking method is prevented.

There doesn't appear to be any syntactical advantage or disadvantage of one over the other as far as parsing the text goes; I think it's more of a preference or implementation issue. The implementation advantage is that the syntax rules I've just described have already been implemented in MegaTWiki. The preference is "let's use dots in the topic text, and slashes in the URL, just like we've been doing all along".

As far as the URL used by the browser goes, I'd prefer to support the "/", as TWiki uses this to separate the Topic from the Web already, and it is used as a directory path separator already, assuming we're using hierarchically nested directories for our storage implementation; this is easiest, both to understand and to implement, as there are minimal changes to the core code and templates for this to occur Today.

I guess the gist is this: The current implementation (at least in MegaTWiki) doesn't necessarily seem all that broken; it handles itself nicely, though it could use a little polishing for consistency (the rename forms still present "/" to the user), and the users generally don't need to think about it all that much. I'll be posting the results of our user survey as soon as I get a decent amount of results back.

-- PeterNixon - 12 Jul 2002

I agree with Peter here, there are no real issues with the code, except for polishing. And nobody seems to have problems with the syntax. So far, nobody seems to have a need for relative web naming as in ../Someweb/TopicName ...

I installed MegaTWiki because of the fact that we have many little teams that all have MeetingNotes and private projects and whatnot, and hierarchical webs are just so much better for that. (also for email notification, you only get notifications from your team and the ones that interest you).

The fact is that we have one server, and many groups that have very low and hierarchical interaction, and therefore we need to reflect that in our TWiki web layout. We simply need this to be useful to many groups here.

So, please add in the necessary changes in BeijingRelease or CairoRelease

-- WoutMertens - 12 Aug 2002

Comments added in table above.

-- JohnTalintyre - 05 Oct 2002

Added to above table/poll.

-- AdamTheo - 22 Dec 2002

Added to above tables/polls.

-- RandyKramer - 18 Feb 2003

I'd like to get some discussion going on providing LogicallyNestedWebs.

-- JohnTalintyre - 06 Jun 2003

I see it's been a while since anyone added to this.

My $.02 -- We have a situation where we, HLUG (Houston Linux Users Group) are using TWiki as a supplement to our regular web site. Hosting is provided by a generous member on his commercial site. This commercial site is physically hosted by a commercial service. He has logical but not physical access to the machine. (Virtual hosting, I believe, forgive my ignorance.) Thus, he feels that setting up a second TWiki site on his "server" is not practical.

If we had hierarchically nested Twiki Webs, presumably with the ability to have their own Main sub webs, then he could have more than one TWiki on the same server.

-- RickArchibald - 28 Jan 2004

One approach that might work is to use Colas's Plugins.KoalaSkin- this allows you to group together webs into logical groups. Whilst this isn't the same as hierarchically nested twiki webs this probably gives you something close to what you want. Failing that, even using the normal skin, but by playing with WIKIWEBSLIST, you might be able to fake it. (Patches for search to limit searches to just the subset might be needed though)

A WIKIWEBLIST approach might work as follows - on Main.TWikiPreferences (don't change TWiki.TWikiPreferences - it makes upgrades more awkward) add settings:

• Set DEFAULTGROUPS = Main TWiki06x01 Plugins
• Set WEBGROUPONE = Webone Webtwo Webthree
• Set WEBGROUPTWO = Webfour Webfive Websix
• Set WEBGROUPTHREE = Webseven Webeight Webnine
• Set WIKIWEBLIST = Webone Webtwo Webthree

Then, in Webone.WebPreferences, Webtwo.WebPreferences, Webthree.WebPreferences set:

• Set WIKIWEBLIST = Webone Webtwo Webthree

... in Webone.WebPreferences, Webtwo.WebPreferences, Webthree.WebPreferences set:

• Set WIKIWEBLIST = Webfour Webfive Websix

... in Webone.WebPreferences, Webtwo.WebPreferences, Webthree.WebPreferences set:

• Set WIKIWEBLIST = Webseven Webeight Webnine

Then aside from searches, the 3 groups of webs will appear to be separate. Personally I think that approach slightly sucks, but it would work in the absence of you using MegaTWiki or Plugins.KoalaSkin .

-- MS - 28 Jan 2004

I'm running into difficulties to deploy TWiki due to the lack of that feature. Any chance that it is available as a patch towards CairoRelease ? I'm having several teams that collaborate on a shared project (one web) refusing to add content because they are concerned of mixing their data with others. The matrix of teamsxprojects is just to big to create a web for each of thoses...

-- GillesEricDescamps - 03 Nov 2004

related to MultiLevelWikiWebs; consider refactoring

A patch against CairoRelease has been posted on MultiLevelWikiWebs.

-- PeterNixon - 29 Jun 2005