I have a strong use-case for this style: large hierarchies, with possibly conflicting names.
In my day-job at GigantiCorp, I’m responsible for an in-house business rules system. This is actually the system I’ve been documenting with TW and which has lead me to create several plug-ins shared here, but I’m also in the process of using TW to dynamically generate user documentation for the rules projects various teams have created.
A project can have many Categories, as well as some small metadata. A Category can have many Rules as well as some significant metadata… A Rule can have multiple Versions as well as some significant metadata. A Version has some metadata and an executable JavaScript code block.
Projects can be large, owned by multiple teams. Most Categories are shared by teams of 5 - 15 developers/business folks. Some categories have one or two rules, some have thousands. There are no overall naming conventions, so CategoryA
and CategoryB
could each have Rule1
, and typically versions are simply named v1
, v2
, …
When a project is built into an executable bundle, I create a wiki from all the data for easier viewing of what’s actually in production. I create data tiddlers for all those levels from the various files generated. But I can’t create just Rule1
, since there may be rules of different categories with the same name. So I have tiddlers with titles such as CategoryA
, CategoryB/meta
, CategoryB/Rule42
, CategoryA/Rule7/v3
. Each tiddler also has one or more tags, always at least one of Category
, Rule
, Version
, Meta
, etc – these are used in view templates and elsewhere.
While I could duplicate this hierarchy using field names or tags, I already have it in the name structure, so it’s what I use to list children in each template. While this is still in the conceptual stage (I’ve created a small sample output wiki, but am not yet generating them live), I did the same thing (with far fewer TW skills) on the predecessor project, and it works quite well.
I’m sure there are other reasonable use-cases as well, especially for dynamically-generated wikis.