Many others have already suggested this, but especially Paul Downes convinced me that SubPages are really a very good idea, i.e. each WikiPage can have an unlimited number of pages that are containing it.

This works well with our current wiki attachments, since they can be considered as sub-pages to the current page. It's also reminiscent of the ReiserFS model, where a file can also be a directory, and then the file's attributes are stored inside the directory. This can also be very useful in context with versioning.

We should probably support both real and virtual SubPages. For example, we could support things like PageName/Versions/15 to get the Version #15 of the page "PageName". Or PageName/AuthorName would always contain the author of the page "PageName".

Syntax issues#

I think we want to use the slash (/) as the separator, as it fits nicely with the current attachment scheme, if you consider WikiAttachments as pages (internally, they *are* considered as WikiPages).

Within the same group of subpages, you should be able to refer to sibling pages using just the page name. For example, two pages PageName/FooBar and PageName/GobbleGook could refer to each other as FooBar and GobbleGook. However, this means that simple cut'n'paste from one page to another page would no longer be possible...

SubPages do nest.

A side issue, but why not support [/picture.gif] now?! Just as a shortcut for [ThisPage/picture.gif]? - YishayMor
In fact, the shortcut is [picture.gif], and it's already there :-) --JanneJalkanen

Path Issues#

I think using slash (/) as a separator is fine, but we should also allow for it at the beginning of the path, too. If you are in PageName and reference FooBar, it should probably look for FooBar in the local grouping (and possibly continue working up the tree (../FooBar, ../../FooBar, etc) if not found in locally?), but you should also be able to reference the page from the root, such as /AnotherPageName/FooBar to specify a page in a different grouping (especially if the SubPage has the same name).

This would boil down to:

  • Every PageName is actually a directory and it's contents are the WikiPages (complete history) and attachments and any meta-information to keep about the page (author name, size, etc.). By default, requesting the directory shows the most recent WikiPage and attachments contained in it.
  • Referencing a SubPage (FooBar) should look for FooBar in the current directory and possibly should work it's way up the tree. This could be confusing though, but I don't know a good way to not break existing pages (since no current pages have any kind of structure to them). This, obviously, would have to be discussed. An unresolved reference to FooBar should create the page in the current directory (or, if a different path is given, use the given path).
  • Absolute and relative paths should work (/) and (..).
  • How would we specify meta-data for attachments? Given the example shown above, if I need version 3 of foo.jpg, would it be /PageName/foo.jpg/Versions/3? That seems a little funky since you wouldn't have to specify the page content for the version to obtain.

Comments? More = better!


Attributes and inheritance#

This is where it gets complicated; SubPages should inherit most of the attributes including access control information from its master page. This allows things like having private areas under your own home page, or web logs where all of the entries are stored under as SubPages, and thus protected by whatever protection is given on the web log front page.


This is likely to be a 3.0 feature. If we go full out (with the metadata-as-files -idea), it probably requires changes to the PageProvider interface, which in turn means that the whole thing should be bumped to 3.0.


Go ahead.

Wouter (2003-09-17): Looks a bit like the Categories-and-XML-storage thingie I was thinking about on my weblog - read for details - and that seems easier to implement (or am I missing something?)...

JanneJalkanen: Yes. This is an issue that is independent of any categories, or storage formats, since SubPages allow also cool things like separate WikiWebs like in TWiki.

EugeneKuzmitsky: OpenWiki has this feature. May be it would be reasonable to refactor its code?

ebu: I wouldn't mind a much faster schedule on this one... One question that comes to mind is the inheritance of access restrictions/rights. If subpages inherit their rights from parents dynamically, and we then add, say, a new group with access to the top level, we'll always have to explicitly go through the subtrees that should be restricted to that group. Ouch.

The metadata issue ties in with something I was mulling over: I have a feeling that a page's access rules should really be in the metadata, and metadata should be stored separately from the page content. This lets us implement different ways of handling metadata and access. The default one could look exactly like the current proposition to the end user. (Although I'm tempted to write a small footer template that has options like delete page, rename page, add/remove permission X to/from entity Y.)

JanneJalkanen: Yes, issues like these are IMHO exactly the reason why Wikis should NOT have fine-grained access control. Things become always very, very complicated whenever security is involved, and I would expect a huge number of bugs in the current implementation alone.

I think we just need to keep it simple - subpages inherit the parent's permissions, and everyone needs to be aware of that. If you add a new group with access rights, it's your problem. Your fault for restricting access to the sublevels... This is the same problem as with any ACL-based system, like Windows.

Matz: I expanded JspWiki to support Subdirectories. I dunno if this breaks with some Wiki rule, but the plan is to allow better structured pages. You just write Links with slashes like Project/Main, Project/Members and so on. It works with the VersioningFileProvider so the corresponding files will be created in sub directories. If someone ist interested, just look at my website (

That sounds like a nice addition. I have always thought the Wiki files become a bit of a mess. However, our main problem is that way users use it. Like, not using reverse naming for sorting. For example, I see pages named, CatProgram, DogProgram, ZebraProgram instead of the much better, ProgramCat, ProgramDog, ProgramZebra. I can see a similar problem with your solution for our use. If this could be integrated more into the Wiki interface it would be better, but I guess this is what the sub pages/category work going on is about. -- KieronWilkinson
You're right: we're using this in an intranet and we had to "encourage" pleople to understand and use the categorization correctly ;). I'm afraid it won't work for an open Wiki if it's not supported by some interface. -- Matz

imario (2004-08-31): I just would like to know if there is still progress on this topic.
Just for fun i tried it with JSPWiki v2.1.106-cvs and i managed to create those files but jspwiki still thinks they are attachements instead of pages. It looks like if we just turn the screw there we could have this feature very soon and without too many changes in jspwiki's core.
If wanted i could dig into it.
This is the only feature i miss for our possible migration from snipsnap to jspwiki.

ShaunMcDonald (2005-03-08): This would be a great addition! It would make life a lot easier.

JoshM (2005-05-10): I agree, the additional organizational value is tremendous. I just got through looking at someone's implementation of the Moin Moin wiki. (which supports subpages well)

ErikAlm, 09-Jun-2005: How about PageName?version=15 when accessing virtual SubPages? Here version would be a meta data value of PageName and of course we could do anything else than version, like: PageName?author=XyZ&date=2005-09-18. Since page?name=value is the standard for URLs maybe it would be easier to understand?

Gregor Hagedorn, 2005-10-07: After reading the MoinMoin topic on subpages I am not sure this is the way to go. Allowing arbitrary nesting and requiring users to navigate when referencing topics (MoinMoin supports things like "wiki:Self:L1/SubPage", "../SubPages", "../", or ":../:free") is fine for programmers, but may be less so for MereMortals and Wiki content authors. I especially dislike the idea that you can no longer refactor content, because all links have to be updated depending on page context. The original Wiki idea is based on simplicity and purposely introduces a flat namespace. Perhaps it is worth separating issues:

  • I do like the idea to access metadata or page versions in a way like page/version/15, or page/author, page/date. Perhaps in addition page/raw or page/rendered (for raw and rendered content, without any "envelope" as currently supplied by the JSPWiki templates) could be supported to simplify integration of Wiki content into distributed services. However, supporting this is entirely independent of supporting subpages.
  • I do like a multiwiki (compare MultiWikiDevelopment). Here some context and locality is provided.
    • This is similar to a one-level subpage Wiki, except that rather than the paradigm of file-system folders, the interwiki paradigm is used.
    • For most purposes, you work inside a flat structure that is your own focussed Wiki web. PageIndex, RecentChanges, RSS by default are inside this Wiki Web.
    • However, you can link content from other Wiki webs, by simply adding the name of the other web like in the well known interwiki links.
    • The JSPWiki software would know about this separation and provide some special methods, like single-sign-on, or searching/indexing/moving/refactoring across the boundaries of Wiki Webs. Furthermore, some Wiki webs could have a built-in special singificance (Meta:, Help:, Users:, Config:, etc.).
    • I believe this is readily understood by content authors, requires no user training (like which out of multiple possible hierarchies should be used!), and supports any kind of refactoring without analysis of hidden information buried in the implicit hierarchies created.

Janne: The real use cases, in my opinion, are things like the ability to put all the Wiki documentation under "Doc/" and protecting them with a simple DENY write Guest on the "Doc" page. Also, I would like to move the WebLogPlugin pages under the page itself (like Main/Blog010203). This would be a lot cleaner. However, I also dislike using relative paths (../Foobar); they get a bit complicated.

I do also like the concept of multiple wikis using a single engine, and I think that BOTH should be supported.

-- JanneJalkanen

The Doc/ use case, including the inheritance of DENY etc. would just as well be handled by setting up a Doc Wiki web (making it "DocWiki:examplepage" instead of "Docpage/examplepage".

In contrast, I agree with respect to the "weblog" or "comment" use cases. As long as these are special cases (and not normal content pages) I see them as parallel to /attach/ inside a page. I would prefer subpages to be limited to known purposes. The advantage is that for content authors the software remains a simple Wiki and no decisions (how do I arrange my pages in a hierarchy?) are requested.

-- Gregor Hagedorn -- 2005-10-9

One maybe far-fetched reason I would want to organize pages in a hierarchy (and that this hierarchy be mapped to a real folder hierarchy) is to be able to export a Wiki contents.

Specifically, one of my Wikis is a document "list", where I attach a lot of tech docs. All the attachments are in their respective <<PageName>>-att folder. If I want to export the overall contents as a zip of files/folders, e.g. to my laptop so as to be able to read these docs offline, the structure of the folders is not very organized. e.g. I have sibling folders Java-att, J2EE-att,... all under a single root folder, whereas I would like to have them organized as <root>/Java/J2EE (which is the navigational way my pages are indeed organized).

That applies too if one wants to export a Wiki to a static HTML site. The static site will be more easily maintained if the contents are organized in a hierarchy of folders.

Note that exporting is probably a utility to be coded in the engine, or in a plugin, or as an offline tool... but for this utility to be able to create a folder structure, it needs to have the logical structure specified somewhere - and SubPage would fit.

-- Jérôme Duprez

The subject of SubPages goes together with the subject of MetaData as in Rolfs subpage requirements

--Rolf Schumacher, 26-May-2006

--rpagnin : I think that subpages will be very useful to categorize pages. I prefer a folder-pages approach, even for administrative pourposes (backup, refactoring, script-generated pages, etc.). Anyway every solution will be welcome.

--rpagnin, 05-Sep-2006


--AnonymousCoward, 28-Dec-2006

While changing the physical organization of wiki data to support a concept of information taxonomy (Hierarchy, WikiWebs, Spaces, SubNav, Area, Topic...) is tempting, it becomes very difficult to change and complicates the system. Pages need to be copied to new locations and deleted from old locations and links break. This begs the question: "Can we keep the flat physical structure while allowing a conceptual hierarchy?"

I want to be able to have a "LeftMenuCategory" (in addition to "LeftMenu", "MyFavorites", and "LeftMenuFooter") that is appropriate to my current page's "Category". I would like the system to recognize the category defined by the page [Category Ideas]] (please see "Category" discussion) and automatically include the "CategoryIdeas" page on the left just below the "LeftMenu". To take it a step further, I might choose then to have the "CategoryIdeas" page simply link the referring pages. In this way, a new page can effectively add itself to the "CategoryIdeas" sub menu specific to it's defined category. Perhaps, a page can even define itself as belonging to multiple categories and thereby have one sub menu for each matching category.

The advantage is that the taxonomy of content is purely conceptual and decoupled from the physical back end structure.

So the question is then, how does a page tag itself with a (or several) categories? How does the system read this information to then include the category named page on the left menu? Perhaps the "MyFavorites" implementation will give us some inspiration?

--Christoph, 08-Aug-2007

I don't see a difference between a flat repository which allows slashes in the page name vs. a hierarchy... I mean, all the filesystems in the world do this, and it is a well-solved problem. The only difficulty comes with relative linking.

--JanneJalkanen, 09-Aug-2007

I see your point, but not all filesystems in the world have documents that interlink among themselves nor are they so prone to reorganization by a host of authors. Relative linking between different hierarchy could be a challenging problem to solve. Page A links to C (A/B/C) and now C is moved (X/Y/Z/C). Is page A's link to C broken? Can C exist as a subtopic of A/B and X/Y/Z concurrently? (Apple is a subtopic of Fruit and Salad.)

In a relative hierarchy a reference to LeftMenu might display the closest relative LeftMenu match. In other words, if the current directory (A/B/C) does not contain a LeftMenu page, then A/B would be searched and then A. In this manner you could get a LeftMenu relative to the current sub category. Very Nice.

--Christoph, 11-Aug-2007

It sounds like what needs to be done is to be able to maintain absolute links, but allow them to be created from relative references.

ie: When a page is created it is assigned a unique flat namespace id. Now as long as that page exists, people can always refer to it by it's flat namespace id (ala blog permalinks). However, when linking to it, people can initially provide only a relative reference to it from the current context. Then when they save, the relative link will become an absolute binding. Thus, if the page get's moved elsewhere it's related links can be automatically migrated.

Ideally the absolute identifier would not be a part of the user view. It would only come into play as needed for a migration or for permalinks.

--AnonymousCoward, 2008-02-06 (ISO 8601)

What is the status on this feature and the timeline? I would love to see it, imho it is really a must.

--AnonymousCoward, 20-Mar-2008

3.0, coming later this year.

--JanneJalkanen, 20-Mar-2008

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-68) was last changed on 22-Mar-2010 22:03 by Allhours