Question. How is a SectionedPage superior to InternalTransclusions? I mean, really, a sectioned page is simply a sequence of InternalTransclusions of pages (possibly anonymous, but not really). It is more powerful and probably just as simple to make the sections separate pages which are emitted together, as you can include the same section in two different pages. You can also create a directed acyclic graph of pages. You'd have to be careful to break cycles, of course.
Note, for an example of how you can emit two types of pages together, click on the diff link at the bottom of the page. You get the QuickDiff? + a preview of the page emitted together. [Actually, difference display is an option of the ordinary page display. It's pretty close to the section idea, where one could choose to display or hide sections.]
This is pretty much the right idea, at least for the initial implementation. (Later people should be able to add non-standard sections and choose to display them.) TransClusion seems very nifty until people actually put it into practice. Implementing transclusion would be a significant change to the current structure of "open only one page per query", but it wouldn't be impossible.
The bigger problem is the interfaces for transclusion. One might start with full-page transclusion, but people will quickly ask to transclude only sections of a document. Then you need to add sectional markup. Seamless transclusion (no borders) makes editing the transcluded material more difficult. Limits of transclusion need to be documented, and error-handling implemented for situations like cycles. (Consider pages A, B, and C. A transcludes B, and B transcludes C. Now if someone edits C to transclude A, one has a cycle. There is nothing within page C to indicate that others are transcluding page C. One needs a full backwards graph to find cycles at edit time.) Of course all of this also needs to be documented...
If people can come up with real examples where TransClusion would be better than existing solutions, I'll reconsider it. Eventually, a future version of ViewPoint should allow assembling pages from arbitrary sections on different pages. Finally, all other things being equal, better is better. Worse-existing tends to be better than better-planned-for-future-version, however. --CliffordAdams
I was also concerned about possible negative effects, especially for whole-page transclusions. For instance, suppose there was a Definition-Of-Transclusion page containing just a brief definition, and it was transcluded in several places. Now suppose someone inserts a long comment on the definition. This could degrade several pages. Where should the person add their comments?
On the positive side, ZWiki:FrontPage seems to be the best use I've seen of wiki TransClusion. I'm not sure if it is greatly better than the usual current/archive split, however. --CliffordAdams
In other news, I have some design notes for the sectioned-db at MbTest:SectionDesign. It really isn't much of a change from the old DB, which was far more generalized than necessary. --CliffordAdams
Another use of this would be to impose variable (context-sensitive) meta-structure on top of the actual content of a page. For example, say you want to add next/previous links to pages to make discussion of certain subjects more linear. As DaveHarris points out on BookMetaphor, if any given page is included in more than one linear thread, then it would have multiple next/previous links. Ideally these sort of things could be hidden from the user unless the user asks to see them or unless they are browsing a linear thread. This requires logic in the server, and I think it could be done cleaner by way of SectionedPage. -- BayleShanks
wow, beautiful implementation too -- available paths are shown in a sidebar to the left, and it look like it is very easy to create a path (change the "page type", and then use a special linking syntax) -- BayleShanks
I implemented this concept - specifically for the purpose of TransClusion of (called named sections for includes) in OWikiClone (a derivative of Twiki and usemod) mid 2003. Prior to this I'd used InternalTransclusion of pages for similar effect (I still use the latter for some uses purposes). Some minor points on the implementation there:
The results of doing this are intriguing :
On a deeper level I'm struck by the idea that a "page" in normal wiki parlance is actually just a way of having the smallest addressable piece of text in the wiki. However that unit of addressing depends on whether the site prefers small pages (favouring linking) or large pages (favouring discussion, discourse, summaries). This has led to one simple thought:
If you use one page per item, you can end up with detailed (useful) pages, on each item. However then it becomes more like wikipedia than a glossary. However if you have a single page, you lose the ability to directly link to the definition. With a SectionedPage you /begin/ to gain the ability to mix the metaphors - the ability to put pages inside container pages, and the ability to directly access them. Put bluntly - if I name a concept on a page it forms a logical section in no different a manner from having a physical page. Why not allow automatic wiki linking to such sections? For example if I type BroadcastingAndMonitoringNews? it would be nice if it linked to that section on UdellOnGroupware directly, but at present I haven't seen any wiki that will do that for me without breaking the page up into lots of smaller pages, thereby breaking the context. (I'd be curious to see one :) This then naturally leads to a fluidity that can allow sites to consolidate small topics to larger ones as time progresses. -- MichaelSamuels