Multi Level Wiki Problem

Greetings!

We are using a Wiki at work to try to resolve the age-old problems associated with documentation. The problem I am encountering is that I can't make my LINKS 'multi-level'. When I have a parent, child, grand child, great-grand child relationship, I can't seem to find a way to make it look like this example. I can get 'Payroll Interface' to show, and to have 'Accounting Data To Payroll' as its child, but I can't figure out how to make 'Perl Extract Routine' a child of 'Accounting Data To Payroll'. The result is too many links where you can't tell how they fit into the schema.

If I combine things to get down to only two levels, then things like 'Perl Extract Routine' - which are used by many different processes - can't be linked to by the other routines because the context is wrong (i.e. it would look like you were linking from Material Management to Payroll, not merely to the Extract routine that they have in common).

I'm hoping ya'll can help me.

Berry

(For the record, we're using UseModWiki v.0.92)

Example (these would all be WikiNames in the real system):

 *Payroll Interface  (this is the only 'main' link I'd like to show)

    **Accounting Data To Payroll (this 'child' has both a parent and a child of its own)

        ***Perl Extract Routine

        ***Accounting Data Server Upload

    **Load Payroll To Financials

        ***Payroll Conversion To Financial Format

---

Are you saying that...

• On a wiki like this
  • there's no way to enter
  • hierarchical information?
    • like this?
  • <end>
• <end>

(If so, I'm sure you can change it to meet your needs! ;-)

No no... Unordered lists I get. It's the creation of hierarchical relationships among WikiNames that I'm trying to understand.

---

I think I understand the problem you're describing, and if so, it's a problem I see too, in using Wiki at my own location. What you'd like is to have WikiSubSpaces, where a given WikiName is not global across the entire Wiki, but rather local to a given subset of pages. Am I right in this assumption? -- MikeSmith

---

No, I'm ok with the WikiName being global across my entire wiki, but I need to be able to create the 'parent/child' relationships that are more than two levels deep. As it is now, I have no way to keep 'Perl Extract' from looking like a parent value, because I can only establish it as a 'child' of 'Accounting Data to Payroll', not a 'grand child' of 'Payroll Interface'.

---

Maybe the solution is not to use a regular Wiki, but some framed web page, where one frame is the hierarchy tree, and the other frame contains the WikiPages.

---

The answer is simple. Write the names of the parents manually. This isn't hard, and it's flexible. See the hierarchy rooted at SelfDocumentingCode for an example. Go to CodeFormatting and then one of its "children" to see a multilevel path. The automatic solutions are complex, I think. See ZwiKi's implementation. While an interesting navigation experiment, I'm not convinced it's the right thing to do. -- SunirShah

---

For the record, Berry, who posted this, is my co-worker. She really wanted to have WikiNames with relationships like Top/Sibling1/Child1; Top/Sibling1/Child2; Top/Sibling2/Child1. I think she posted here mostly because I interested her in Wiki in general and ThisWiki in particular. Funny thing is, I never realized that this was here until today.

The solution (such as it is) that I came up with was to use mkpath instead of mkdir in the page directory creation subroutines, with the concomitant changes in the sub-page code elsewhere, especially where references to $MainPage are found. This allows the hierarchical structure she so desired, but at the price of portablity and the global Wiki namespace (to refer to a 'Deep Link', as I call it, you must use the entire path e.g. PayrollInterface/AccountingDataToPayroll/PerlExtractRoutine). It might not be the best solution, but it was the SimplestThingThatCouldPossiblyWork (that I could come up with in the time alloted). -- PrestonRickwood

Funny, I insisted on disabling SubPages on MeatballWiki because I thought my solution was the simplest thing that could possibly work. -- SunirShah

---

Thanks for your input, Sunir. Our current use of the wiki is attempting to overcome some collaboration efforts at disparate locations, with predominently 'functional' types using it. The wiki provides a freeware solution, which is web deployable, and infinitely flexible.

Functionals see everything as hierarchies, but can come to understand refactoring concepts well enough to know to link in pages that are germane to something they're doing, rather than rewriting something over and over merely because it applies to a new circumstance (and thus having a million places that need to be maintained when things change - the bane of bad code and bad documentation...). Having the ability to make things several levels deep allows them to limit the number of 'top' pages, while still maintaining the most detailed levels of 'sub information', and in addition being able to link in germane pages (like table descriptions), all the while organizing it in the way that is meaningful to them.

I think this is the mappers vs. packers distinction in TheProgrammersStone rearing again. Your problem is exactly why people should take a lot of care in how they select their LinkPattern and link structure, because it influences how the system is used. I disabled SubPages because I like building relationships freely. You sound like you'd like, well, a multi-level wiki because that more naturally represents the problem you're trying to describe. I similarly hacked the LinkPattern on a wiki I was using to write a paper to make paper references like [Foo99] page links. -- SunirShah