UseModWiki | RecentChanges | Preferences

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:

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?

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.

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

UseModWiki | RecentChanges | Preferences
Edit text of this page | View other revisions | Search MetaWiki
Last edited February 11, 2017 12:02 pm by MarkusLude (diff)