UseMod Wiki: SubPage

The SubPage idea allows every main page to contain its own wiki universe of subpages. The subpages can be used to help refactor a large page without the problems of a /LongPrefixBeforeEachPage.

Subpages of a common topic can easily refer to each other without a prefix, while outside pages require the prefix. (One could consider a "search path" extension to allow groups of pages to share subtopics.)

The SubPage can also be used to expand ideas into other pages, especially when one is uncertain whether the idea deserves a full top-level page.

SubPage ideas:

/RecentChanges (multiple ideas)
/HouseKeeping (reorganizing notes)
/Discuss (useful for maintaining DocumentMode?)
/InfoHiding (lists, "bookmarks")
/GroupInfo (meeting plans, etc)
/SandBox? (experiments, auto-edits)
/SubPageQuestions (trying to grasp the concept of Sub Pages)

SubPages are not intended to replace categories. Subpages are also not intended to create a hierarchy-style classification--there is only one level of subpages, and a subpage can only belong to one main page. It would be interesting to see if a community likes this concept.

Why are hierarchy-style subpages a bad idea? - JimMahoney

That's a really good question. I myself would love to have hierarchical-style subpages. --ThomasHammer

Then you could get into things like absolute vs. relative pathnames. It might be more of a mess than a pleasantry. -- Wiki:EdwardKiser

Using twiki, I often longed for multilevel nesting of hierarchies to conserve the namespace. I envision a 1:1 correspondence between filesystem directory structure (folders to Windoze) and the Wiki space. Yes, it has exactly the same problems with naming that a filesystem does - wiki *is* just a nice user interface to a datastore. Wiki editting allows us to easily create and edit (and link) text files. Hierarchy requires a similar interface extension to handle directories. -- AndyGlew. Wiki:AndyGlew

: I'me with you on that one. I just started playing with wiki. We know that with hyperlinks it doesn't matter what the document structure is on the filesystem, whether it's flat or tree-like. But it does matter for navigation. So when I played with sub-pages, I was delighted to see that each subpage aquired a link to its parent page. That makes navigation much easier. One of our non-techies created a few references to Unix commands and utilities he is competent enough to use. I made each of those references sub-pages of "Unix Commands and Utilities." Each reference then had a link to its parent. Wonderful! Even better would be if each sub-page carries a navigation bar with links to each of its siblings because otherwise you have to add them manually (which is a pain, particularly when new siblings get added). Basking in my success, I made Unix a sub-page of HowTos and I made the command references sub-sub-pages under the Unix sub-page. Which doesn't work. Waaaaaaaaaaaaaaaaaah!

: Some wikis work fine with a flat structure. Others need a heirarchical structure. If the wiki supports a heirarchical structure then those wikis that do not need it just ignore the mechanism. If the wiki does not support a heirarchical structure then those wikis that would benefit from it have to suffer. --pla

Given that UseModWiki does not support such hierarchy, does anyone know of a Wiki that does?

I believe that Zwiki and coWiki both support some kind of web page hierarchy. If there are others, I'd love to find out.
- WikkiTikkiTavi now supports multiple levels of subpages, see Tavi:TaviSubPages?. This in combination with the Tavi:TaciMacros/TitleSearch?, which produces listes of page titles make a very powerful duo. Each SubPage displays all parent pages, and if so wanted one could easily create an index on this pages listing siblings or childs of that page. --Tavi:EvenHolen?

By the way, when you say

     SubPages are not intended to replace categories.

would you be willing to write up a wiki page describing how categories should be used?

Fitnesse has a great implementation of hierarchical wiki structure. Its written in Java with some 9 developers working on it at SourceForge.net and is actually an acceptance testing framework (xtreme programming/GoF?) with a wiki built in for collaboration. So the wiki was actually a secondary consideration but still very integral to its functionality. They couldnt use a flat file structure due to namespace collisions that would make multiple projects impossible on the same testing environment. So they *gasp* commited wiki sacrilege and went hierarchical to *avoid* the happy collisions that many wiki purists are proponents of.

But the hierarchical functionality is just what I needed. Each wiki page is stored in its own directory. I can have multiple pages that are spelled exactly the same way in the same wiki but whos meaning changes acording to their surrounding context, (parent/children pages). No 'happy collisions' here, but collisions weren't making me happy in my case. It can hold as many wikis as you want, limited only by disk space. Has versioning.

I looked around a long time with no luck until Fitnesse. I had to yank a lot of the testing functionality out of the way for my use but it wasnt that difficult. The wiki itself isn't extremely evolved but its not bad either, and besides normal flat wiki structures were out of the question for me. The code is excellent and *no* file server is necessary. They built one in and the cool thing is that I had it up and running 5 minutes after I started installing it. Although I had Tomcat installed, Fitnesse didnt need it. Very stable.

I thought that the 'leaky-wiki' zWiki (a Zope memory leak problem... no slight intended towards Zwiki...) was flat, but I looked and it does seem to support hierarchies. Cool. coWiki supports hierarchies too but is slow (PHP/p-code) and targetted mainly to *nix machines by the developers.

...community likes this concept...

We just started to use the subpage feature in the DseWiki? and the community seems to like it. We have a place were we *really* need it: open FAQ development with the questions as subpages. There is a vivid discussion and I think that there are a number of open questions, problems and opportunities. I will report in a few weeks. I suggest a new term "PageGroup". -- HelmutLeitner

How about "folder"? Or "directory"? -- AndyGlew (Sorry, couldn't resist.)

Folders (or categories) are used to group arbitrary pages by adding e. g. FolderHomePage. Pages of members are not subpages. -- hl

The VisualFoxProWiki has a slightly similar concept with hidden "underline" pages. These pages are hidden from RecentChanges, but they share the top level namespace.

Other misc ideas:

One could "promote" a subpage to a top-page, and then automatically search and replace references to the new top-level references. One might be able to do the reverse (top-level to subpage) to help in moving things around.

Optional navigation sections, using a standard format. Could do it using another database field, but this way might be better.

Searches should organize the subpages somehow. Possibly for display, first print the mainpage, then set main_page and show the rest in /SubpageFormat?.

I have used a subpage-like feature in my Python-based Wiki. They are really useful for a personal Wiki. Since I am the only user, imposing my own structure on the namespace helps a lot. I only go one layer deep with it. -- SteveHowell

I'm experimenting with SubPage for MycoWiki, a place to collect taxanomic data about fungi. The main pages each represent an important identification character like SporePrint?. The SubPages represent possible values for that character, e.g. SporePrint/Brown?. I'm treating SubPages as a key/value mechanism. -- PiggyYarroll

I've had bad experiences with just one level of subpages. It turned out messy. --Sunnan

PeerPage? instead of SubPage

I have used a hacked version of QuickiWiki? where dot prefixed wikiwords replaces the tail of the current page adress. The tail being characters after the last dot.

Dots immediatly preceding capital letters are considered parts of wikiwords.
Two dots can precede a wikiword in which case
- to form the page adress to get, two dots are eaten from the tail of the current page adress before concatenating it with the wikiword
- to form the page name to present to the user one dot is eaten from the tail before concatenating it with the wikiword. This is the adress used when forming new pageadresses with the dotting scheme.

I have found this useful when structuring pages from different projects, you don´t need to write long wikiwords.

(Indeed, but instead of wikiwords you have slashes :-)

Doubledotting is useful when using a common index structure in different projects. --prErr

ZwiKi? does indeed have strong support for page hierarchy. It was one of the first engines to explore this area. Note that pages are (can be) arranged in a hierarchy but urls and links are not, it is still a single flat wiki namespace as far as urls and wiki links are concerned.

SmallWiki? is another engine with support for hierarchy. Here the urls are hierarchical and the wiki links work in some (unknown) way.

I'm one of those "purists" who prefer a flat name space for wikipages, and that's for a reason: it makes programming easier, and it better lends itself to have pages stored in a database rather than in a filesystem structure if necessary. OTOH, some form of hierarchy can indeed be useful, so I was wandering how to introduce a hierarchy in an otherwise flat space. I was thinking of having an optional prefix before a wiki word, say myprefix:MyPage?, and have the wiki rendering engine display only the MyPage? bit. In this way we introduce a pseudo-cathegorization in the name space and still keep it flat. In other words, a PageWithLongPrefixBeforePageName? of a flat space would be written as pagewithlongprefixbefore:PageName? . Just a hint, I would appreciate comments on this. Also, of the wiki engines that I have stumbled upon at least PmWiki and http://www.wikidot.com use a similar concept. --Carlo

: One way of achieving this is with WikiPatches/HierarchicalUsemodWiki -- UngarPeter