This is a Main re-edit -- AndreaSterbini

It's possible to use wikiwebs directories with more levels, i.e. to define SubWebs under a WikiWeb and so on ... (an example of SubWeb could be a web named Web.SubWeb1.SubWeb2 , that corresponds to the directory Web/SubWeb1/SubWeb2 ).

The requirements I would ask for a tree structured Web (see HierarchicallyNestedTwikiWebs) are:

• We can define webs inside webs.
• a link to a topic in a subweb is just a sequence of words separated by dots/slashes and with last word being a valid topic name (e.g. Foo.Bar.Baz.HelloWorld).
• to ease the navigation, the names of the webs along the path are links to the corresponding main web page.
• included files/topics, templates and WebPreferences are inherited

I have made some modifications to the wiki.pl and wikicfg.pl files to handle the above ideas. I enclose them as attachments in the file https://twiki.org/p/pub/Codev/MultiLevelWikiWebs/twiki.diff (patch against twiki beta of 15 Aug 2000, please discard the other two older attachments). (the file contains also the code/template/topic for my GetAWebAddOn utility)

Notice the usage of the %WEB% tag in templates covers two different needs:

• it is the path of a Web in a URL
• it is the name of the web to be shown on the page

I propose we differentiate the two usages by introducing the new variable %WEBNAME%.

In twiki.diff you can find also the modifications applied to templates.

The changes in templates produce a sort of link list in the web name that could be used to navigate to the above webs.

Here I enclose some part of the modifications:

To render hierarchical web names

[use the WebnamesPlugin attached to TWikiPluginAPI] -- AndreaSterbini - 25 Oct 2000

-- AndreaSterbini - 19 Aug 2000

---

Note: I suggest to change the standard setting of the %WIKIWEBLIST% and the %WIKITOPICLIST% variables so that:

• %WIKIWEBLIST% shows only the webs normally reachable from this web (it's not needed that we repeat the TWiki.%WEB%.{ path ... it's already shown to the left)
• %WIKITOPICLIST% shows only the available operations.

-- AndreaSterbini - 19 Aug 2000

I have noticed that showing the full web path of each link in the bulk of the text is not user-friendly.

NOTE I have changed the routine above, now it is slightly better. Use this version after having applied the diffs.

-- AndreaSterbini - 22 Aug 2000

---

Thanks Andrea for taking this initiative. There are certainly installations where nested webs make sense. I am however not convinced that this is a feature most users need. The MultiLevelWikiWebs functionality adds complexity in the code and user interface. I propose to leave it as a FeatureBrainstorming, or change it to a FeatureAddOn when ironed out.

We get most of the MultiLevelWikiWebs functionality if we improve the navigation within a web. This leads to NavigationByTopicContext.

-- PeterThoeny - 29 Aug 2000

---

[I agree with you, this should be ironed out and become a FeatureAddOn ]

I have noticed that, when the code above renders the main topic name of a subweb, the WebHome link shown give no information to the user. I have changed the code above so that it shows:

Text input	Links shown
Web.Web1.Web2.	Web.Web1.Web2.
Web.Web1.Web2.TopicName	Web.Web1.Web2.TopicName
Web.Web1.Web2.WebHome	Web.Web1.Web2.

PS my interest in having a HierarchicallyNestedTwikiWebs is:

• the hope that there is a way to manage UserAuthorizationSchemes through the Apache autentication mechanism .
• the desire to use separate subwebs to implement a simple WorkFlow , through the movement of topics/attachments between directories.

Pro:

• we have a single place to store user authentication (the htpasswd file)
• we leave security issues to the Apache team

-- AndreaSterbini - 31 Aug 2000

---

Re: Your PS :

1. I intend to solve UserAuthorizationSchemes by AuthenticationBasedOnGroups. That way we use the basic authentication of the web server to authenticate users, and on top of that, use group authentication based on TWiki itself.

2. WorkFlow could be solved with TWikiCategoryTables within one web.

Nevertheless, we could take some required changes for multi level webs into the TWiki core as long as it does not degrade performance or simplicity of the code. That way it would be easier to add the add-on. But I prefer not to document it, e.g. not to make multi level webs a new TWiki feature.

-- PeterThoeny - 03 Sep 2000

---

In my opinion what is now a page could become a subweb. I'm considering the following approach for my WebTeach project:

• Accessing a subweb without specifying a page resuts in accessing the WebHome page (analogous to index.html)
• Comments to a page (see WebTeach) are stored in the Comments subweb of the same page
• attachments are stored in this directory
• preferences and access rules can be specified in the WebPreferences page instead of in the page itself

the pros are that one can move a page (with attachments and comments) from a point to another without problems, creation of a new web is trivial as creating a new page, and one can easily implements inheritation of properties (such as authorization)

-- FrancoBagnoli - 26 Sep 2000

I have forgot to say that to finish MultiLevelWikiWebs we need also recursive versions of:

• mailnotify (I must upload it)
• webchanges
• search?

See the WebnamesPlugin attached to TWikiPluginAPI for a pluggable implementation of the rendering rules.

-- AndreaSterbini - 25 Oct 2000

The files are compressed with bzip2. Non-linux people can find tools for this at http://sources.redhat.com/bzip2/ (its standard for linux apparently, but I'm on a sun/windows combination)

Also, Andrea's changes are not for the 01dec00 release, I'll be fixing them to work, and may have the time update the diffs.

-- StanleyKnutson - 04 Jan 2001

(I apologize for the bz2 files ... I keep forgetting that there is still somebody using Windo$ out there )

I enclose here a new set of patches that introduce a configuration variable and some utility functions:

• getSubWebs($webName) returns all the dirs names contained in a Web directory
• $subWebsAllowedP if true (1) then subwebs are allowed inside webs
• getAllWebs() if $subWebsAllowedP is true, recursively scans the web tree and returns all web names (as slashed dirs)
• getTopicsNames($webName) returns all topic names in a web

By changing a couple of lines in

• mailnotify
• webchanges
• search

we get a better MultiLevelWikiWebs support.

TODO:

• check for user access?
• untaint web name?

NOTE: the diffs below (subweb.diff) contains also a subroutine for ExtendingTableSyntax. Once patched, remove sub emitTR in wikicfg.pm

-- AndreaSterbini - 17 Jan 2001

I found the mapping of Web1.Web2.Web3 matching did not work properly with Andrea's version of Oct 1999. In particular, the strings "1.2.3" and "..." were being matched. Also, I wanted to allow Web3.Sub4 to be referenced from within Web2 to be rendered in a way that included a link to Web3 top level.

I've also implemented a Javascript "jump to" pulldown that allows the template to have a pulldown menu of choices under a web, based on a ModuleList topic. This is a %MODULELIST% substitution in the view template.

The uploaded file is multilevel-web-patches-19jan01.text Those patches build on the verion of 19oct1999.

-- StanleyKnutson - 19 Jan 2001

Hey, I question as to whether subwebs are a good idea. I appreciate that it may benefit in terms of performance, but subwebs are effectively 1) a fixed category and 2) mean that any given WikiWord has a separate domain of meaning.

Can I question how you use them?

Hmm. Maybe the point is that it is useful in certain circumstances. Like, for instance if you wanted to compare different peoples understandings. Gosh, you could use this to compare meanings by seeking the same WikiWord down a hierarchy.

Since I first made this point, I now reckon that SubWebs are a fantastic idea as long as the SubWebs are chosen appropriately. SubWebs are effectively namespaces and this can be great if they represent different people's views.

-- MartinCleaver - 19 Feb 2001

Why multilevel webs

Consider a 'directory of documents' with structure:

   design
      module1
         spec
         details
      module2
         spec
         details
   user-manual
      ...

These are not twiki documents: MS word, Visio and HTML files are the primary components.

The goal is to have a twiki that mirrors the same structure so as to allow comments and more free flowing notes to be taken in the same categorization as the documents are filed.

I'm still working on getting this implemented - I'm selling the concept of using CVS Webedit for access to these documents.

It's been a bit hard to get internal buy-in to using TWiki since some people insist on worrying about the print format of the document. As a result, they really won't use anything except MS Word for their document.

For some other people in the group have been more willing to consider TopicFrames approach to creating a "book" using TWiki.

-- StanleyKnutson - 24 Feb 2001

I'm adding this comment out-of-order, neext to the old comment of StanleyKnutson that I want to add to, rather than at the bottom where the connect is not obvious. I hope that's not too much of a violation of wiki etiquette.

Not only do I wish to

• The goal is to have a twiki that mirrors the same structure so as to allow comments and more free flowing notes to be taken in the same categorization as the documents are filed.

I would also very much like it if it were possible for the TWiki text to lie in the same filesystem. I.e. I would like a twiki in the project filesystem.

As for the earlier comment about wikiwords having separate domains of meaning in any nested subweb, yes, well, that's the idea. wikiwords already have different meanings per web. The trouble is, there is no inheritance mechanism, no way in which all of the wikiwords in a parent web can be inherited, except for one being changed.

Names are a scarce resource. Allowing names to be overloaded is good.

-- AndyGlew - 29 Dec 2003

Hi Stanley, nice to hear that CvsWebClient (http://cvswebclient.sourceforge.net) is getting some airtime! I'd be extremely interested in your ideas and your code, as it sounds like we have similar goals. I'd be keen to explore TWikiMeetsCVSWebClient - perhaps you would like to start it?

I am currently of the opinion that webs can be helpfully compared to a "context", and I think context is a semantically richer term to use.

-- MartinCleaver - 11 Mar 2001

I want to finish this extension for the WebTeach project. Here are some ideas :

• transform all topics to directories where the content is stored in WebHome.txt
  • attachments are files in a directory (could they be topic themselves?)
  • easy creation of subwebs (they are just topics)
• preferences
  • preferences are collected in the following order:
    • TWiki, web, subweb, ..., topic, user
    • this means that preferences are inherited
  • create topic preferences the first time you edit it
• templates
  • templates are looked for from the topic directory up to the root directory
  • this means that templates also are inherited
• show links as in HierarchicalNavigation (see also the WikinamesPlugin)
• use interchangeably both the dotted and the slashed topic notation in urls (i.e. use web1.subweb.topic and web1.subweb.topic)
• mailnotify, searches, index, changes and statistics:
  • recursively visit directories (if configured this way)
  • single configuration for a whole subdir

-- AndreaSterbini - 17 Apr 2001

Another idea is to keep the simplistic one level web but offer the illusion of nested webs as described in HierarchicalNavigation. This would keep the internal design as simple as it is.

-- PeterThoeny - 26 Apr 2001

I've started a new page to discuss the possible ways of storing the data for multilevel webs, DataStorageForMultiLevelWikiWebs.

-- RandyKramer - 12 Jun 2001

Will this work on the latest beta?? If not, is anyone looking into merging any needed changes? I would really like to see this as at least an optional feature for TWiki!

-- DavidLeBlanc - 28 Mar 2002

MegaTWiki currently implements this, along with tools for management of multilevel webs. take a gander here.

-- PeterNixon - 25 Jun 2002

updated to ChangeProposalForm

-- MattWilkie - 23 Feb 2005

Summary of Oustanding Issues

(is that true? i just transferred what was in the form's OustandingIssues)

1. adds complexity in the code
   • no, i completely reject this statement. in fact, this features provides an opportunity to reduce complexity by normalising, refactoring, and genrealising the code.

1. adds complexity in the user interface

1. better implemented as a FeatureAddOn

related to HierarchicallyNestedTwikiWebs; consider refactoring

-- WillNorris - 26 May 2005

So what's the specific proposal? AFAICT there isn't one. The logical way to go about this is to implement a sensible data model (TopicObjectModel). Since that isn't going to happen for DakarRelease, So I'm bumping this to Edinburgh.

-- CrawfordCurrie - 06 Jun 2005

I'm working on a core-level patch for CairoRelease which implements MultiLevelWikiWebs if anyone's interested. It's not particularly pretty, but it works well. See MegaTWiki.

-- PeterNixon - 24 Jun 2005

Actually, I'm going to try doing it for DakarRelease, hopefully in the form of a FeatureAddOn.

-- PeterNixon - 26 Jun 2005

although i summarised the outstanding issues, i don't agree with the statement "better implemented as a FeatureAddOn" for the reason CrawfordCurrie mentioned (better to refactor the core code to handle this properly, afaict that is the way forward to reduce the complexity of the existing code)

i'm reassigning this to DakarRelease in the hopes that PeterNixon's attempt will bear fruit. if not, this is not a requirement for DakarRelease.

-- WillNorris - 26 Jun 2005

Here's a patch against the SVN trunk (svn co http://svn.twiki.org/svn/twiki/trunk .) version 4428 which implements MultiLevelWikiWebs basics. No template changes yet.

• multilevelwikiwebs.4428.diff.gz (Full patch against 4428)
• multilevelwikiwebs.4447.diff.gz (Same patch, but against 4447)
• multilevelwikiwebs.cairo.diff.gz: Same patch as mutlilevelwikiwebs.4428.diff.gz, but against cairo release.

What changed:

• lib/TWiki.pm: updated initialize to handle multi-level web names, added $regex{hierWebNameRegex}, used in place of $regex{webNameRegex}
• lib/TWiki/Search.pm: Added subWeb search (off by default)
• lib/TWiki/Render.pm: updated rendering of multi-level web names
• lib/TWiki/Prefs.pm: subwebs now inherit preferences from parent web (Sandbox/Subweb inherits from Sandbox)
• lib/TWiki/Store.pm: turned on subWebsAllowedP
• lib/TWiki/UI/Search.pm: added "subweb" argument
• bin/mailnotify: now gets web list via TWiki::getPublicWebList() rather than direct readdir

-- PeterNixon - 27 Jun 2005

i have created http://svn.twiki.org/svn/twiki/scratch/MultiLevelWikiWebs/ to make this ongoing work easier to merge. when ready, it can be merged to the DakarRelease branch proper.

-- WillNorris - 28 Jun 2005

Would it alo be possible to have a running version of that as a demo?

-- AntonAylward - 28 Jun 2005

I'll merge the previous changes onto the new branch WillNorris created in the next day or so. Guess I wasn't actually looking at DakarRelease code; the stuff on Will's branch looks very different. Has it ever been on svn?

-- PeterNixon - 28 Jun 2005

here is how i created the MultiLevelWikiWebs branch: svn copy http://svn.twiki.org/svn/twiki/branches/DEVELOP http://svn.twiki.org/svn/twiki/scratch/MultiLevelWikiWebs

esp. see HowDoesTheDEVELOPBranchWork, DakarDesignPrinciples, and DakarReleaseNotes, and naturally, DakarRelease

-- WillNorris - 28 Jun 2005

Thanks, I was assuming that trunk==branches/DEVELOP. I'm all set with that, and am about 1/2 way through merging things in. I have a day-long meeting tomorrow, so I probably won't finish my initial cut until 30 Jun.

-- PeterNixon - 28 Jun 2005

The diff fo 4447 doesn't apply to 4447 using patch. I'm guessing that there are other changes in your 4447......?

-- CrawfordCurrie - 28 Jun 2005

Sorry 'bout that, 4447 patch was against svn co http://svn.twiki.org/svn/twiki/trunk -r4447 . rather than the DEVELOP branch which I had intended. I have a patch coming soon for http://svn.twiki.org/svn/twiki/scratch/MultiLevelWikiWebs

-- PeterNixon - 28 Jun 2005

As promised, here's a patch against the http://svn.twiki.org/svn/twiki/scratch/MultiLevelWikiWebs branch, version 4449. I've used this diff to successfully patch a freshly created working dir.

• MultiLevelWikiWebs.4449.diff.gz: Patch against branches/MultiLevelWikiWebs version 4449

You should see this:

% patch -p0 < MultiLevelWikiWebs.4449.diff
patching file lib/TWiki.pm
patching file lib/TWiki.cfg
patching file lib/TWiki/Search.pm
patching file lib/TWiki/Render.pm
patching file lib/TWiki/Prefs.pm
patching file lib/TWiki/Store.pm
patching file lib/TWiki/UI/Search.pm
patching file lib/LocalSite.cfg.txt

The patch to lib/LocalSite.cfg.txt adds a new variable $cfg{enableHierarchicalWebs} which turns on subWeb listings in TWiki::Store::getListOfWebs(). You must enable it (set it to 1) to get MultiLevelWikiWebs functionality.

-- PeterNixon - 29 Jun 2005

thanks peter. i checked your changes in. unfortunately, i have no time for testing it atm, but i should have some free time this thursday. SVN 4450--4452.

-- WillNorris - 29 Jun 2005

Is there any desire to put the RenameWeb functionality in core code, or leave it as a plugin or addon? If it's headed into the core code, what's a good home for it? This is probably better discussed in RenameWeb.

-- PeterNixon - 29 Jun 2005

I'm planning on combing through the code in the next couple of days to find any TWiki variable handler that can take a web name as an argument to make sure that Thisweb.Thatweb becomes Thisweb/Thatweb in the code. Either that, or Store.pm should just be updated to deal with either, and all queries from anywhere about data and pub directories should go through Store.

-- PeterNixon - 29 Jun 2005

Found some issue with renaming topics between webs. I'm going to work on that code a bit today (replaceWebInternalReferences in Render.pm). FYI, I've been checking these changes back into the branches/MultiLevelWikiWebs branch, so feel free to svn update and give it a spin.

-- PeterNixon - 30 Jun 2005

All set with BugInTopicRenaming as far as I can tell. Try moving some stuff around and see if you can catch anything. On to RenameWeb work.

-- PeterNixon - 30 Jun 2005

Do folks want me to start merging these changes into the DEVELOP branch, or do we want it to finish up on MultiLevelWikiWebs branch first?

-- PeterNixon - 01 Jul 2005

What do you have so far? MultiLevelWikiWebs and RenameWeb?

-- RafaelAlvarez - 01 Jul 2005

Just MultiLevelWikiWebs. RenameWeb will take a couple more days.

-- PeterNixon - 02 Jul 2005

Before you merge anything to DEVELOP, here's the checklist:

1. Merge out from DEVELOP first,
2. All the unit testcases in test/unit should pass,
3. All the automatic tests in TestCases web should pass.

Once those are OK, feel free to merge!

-- CrawfordCurrie - 02 Jul 2005

It took less time than I thought it would, but I've pretty much finished RenameWeb implementation. I still need to update the ManagingWebs doc before I commit the last major changes to the MultiLevelWikiWebs branch. Once that's all set, I'll begin the merge-out/test/merge-in process above.

-- PeterNixon - 02 Jul 2005

RenameWeb changes have been committed to the MultiLevelWikiWebs branch. I'm putting together a total patch and see what works against the DEVELOP branch (running tests before and after of course).

-- PeterNixon - 02 Jul 2005

MultiLevelWikiWebs functionality has been merged back into the DEVELOP branch after completing testing. Tests which failed in the previous version (4516) failed the same way in the new version (4517). No new failures detected.

-- PeterNixon - 04 Jul 2005

Cool! Thanks Peter!

-- CrawfordCurrie - 04 Jul 2005

OK, so we have the code. Where's the documentation? I don't see a data/TWiki/MultiLevelWebs.txt anywhere.

-- AntonAylward - 05 Jul 2005

Thanks Peter! Some further notes:

1. I moved the setting out of LocalSite.cfg.txt (which is pretty much redundant now we have configure) and into the right place in TWiki.cfg
2. I recoded getListOfWebs for efficiency. We eliminated the -d for a good reason.
3. I eliminated TWiki::sysCmd. If you dislike the implementation of TWiki::Sandbox, then fix it, don't just hack around it. That's how the TWiki code got in such a mess to start with.
4. When moving a web, a lock is taken on the WebPreferences. Surely this is inadequate? It should lock every topic in the web, otherwise someone might be editing and the web suddenly disappears?
5. The access checking was very confusing, so I recoded it. Please check what I did; if it's wrong, then it's because I couldn't understand the old code.
6. What was supposed to happen when the target web exists? AFAICT if a topic exists in both webs (e.g. WebHome) it would overwrite the target web. In this case, the access control checks were inadequate; it would have to access-check every individual topic, as topic level controls override web controls. I have made it impossible to rename a web to an existing name until this is better understood.
7. The documentation of moveWeb didn't reflect the contract expressed by the code. It looked like the comment was just a cut-and-paste from the topic move.
8. I couldn't find the unit tests fore move web or rename web. Did you remember to merge them across? I expected to see a moveWeb test in StoreTests.pm, and a rename test in RenameTests.pm
9. There seems to be a lot of code duplication between newTopicScreen and newWebScreen. Couldn't this duplication be eliminated? Also updateReferringTopics and updateWebReferringTopics? Having put a lot of effort into eliminating code duplication, I hate to see more being added....
10. Please remember to update the documentation in TWikiScripts with any script parameters you added

SVN 4527

-- CrawfordCurrie - 05 Jul 2005

Ahh, documentation was always my weakness. I'll get on it later today.

On Crawford's comments:

Had no idea what TWiki::Sandbox was for; the name doesn't imply "system commands" or "system utilities", so I wouldn't say I hacked around it. I think it'd be more appropriately named Util.pm or System.pm, but I'll use it from now on.

RenameWeb:

I built the RenameWeb functionality based on my current 4-year-old implementation, with the intention of improving it. Crawford has "read my mind" on several problem areas:

The lock really should be taken on every topic in the target web before the move, but that might prove impractical, unless the UI can 'pend' until all topics are locked. For now, we can try this:

1. "throw the dice" and try to lock everthing at once (webs and subwebs).
2. Give an oops screen if the user doesn't have permission (list all topics affected), otherwise continue.
3. Give an error message if it can't lock everything. Give the option to leave everything that's currently locked in that web locked until you can try again before the timeout.
   • This'll require an additional screen with a 'Refresh' button.
4. Continue with rename if all topics under the target web are locked.

Permissions should be determined from Every topic under the target web and Every topic in all the other webs which will be modified as a result. Topics which the user doesn't have permission to modify should be listed, and that should prevent the user from proceeding with the web rename. On top of all that checking, I'd propose adding an ALLOW/DENYRENAMEWEB preference which would be checked first before checking topic preferences.

I'm thinking a web rename could only reasonably be done by the TWikiAdminGroup in higher level webs. Doing a rename of a web the size of Codev could take a considerable amount of time on an inferior server.

Documentation:

Yes, it's a bit light. I mostly wanted to squinch the code in first before too much code in SVN changed, followed by better docs, tests, and code improvements.

Code:

As far as shared code goes, re-writing some of the existing code on the first go was too risky. I wanted to get the initial functionality in with minimal disturbances, and then go in and start merging duplicated code after writing some tests for what I initially added.

So I guess you could say I'm about half way there.

Thanks for the feedback, keep it coming

-- PeterNixon - 05 Jul 2005

One can turn off this functionality by using configure. i moved the control. It's in "Misc"

-- CrawfordCurrie - 06 Jul 2005

Peter, is this going to get any more work before DakarRelease? Otherwise we are going to have to ship with the feature disabled. As it stands, the support is all there, AFACIT, but largely untested and without a UI. Am I right?

-- CrawfordCurrie - 15 Jul 2005

Sorry for the delay; I should have time over this next week to spend on it.

-- PeterNixon - 30 Jul 2005

The changes I mentioned above (aside from ALLOW/DENYRENAMEWEB) are now merged into the develop branch. See the ManagingWebs topic in the DakarRelease for an update. If this is still too light, please give suggestions for changes. I have merged duplicated code where appropriate. There still aren't any tests specifically for this code; I have done manual testing, however, and all appears to be ok on a fresh release area.

-- PeterNixon - 01 Aug 2005

Seems to work. Optionally enabled in configure. -- CrawfordCurrie - 28 Aug 2005