Posted by FuzzicalLogic on 02 Mar 2009 09:25, last edited by Heather Partridge on 15 Sep 2015 18:02
Introduction
I developed this after a need to consolidate and limit my navigation, but still allow dynamic growth. Additionally, I wanted to be able to preview structured data. This was the second method I devised along the way to achieving my aim. There were a number of problems to overcome in order to bypass the limitations that each module imposed.
I wanted to maintain a Parent/Child structure, for instance, but I didn't want to have to consistently tell my pages that were spawned off my parent pages who they belonged to. So what I needed was an enforceable hierarchical structure that was dynamic enough to work with ListPages as a tricksy query interface. This is what I came up with.
Tag Trees
What is a Tag Tree?
A Tag Tree is a tag structure that is similar to a category tree (found on other Wikis) and bears strong resemblance to the way Parent and Child pages work. A more precise definition is that a Tag Tree is a heirarchical implementation of tags and how they are used on pages. That is one tag leads to pages that have a "child tag" which further leads to "child pages".
"When and Why would I use this?"
Tag Trees are an efficient way to create dynamically generated pages or partial pages. In particular, on Wikidot, a solid Tag Tree allows you to utilize the ListPages module with simulated Parent/Child pages. This means that unlike ChildPages or Backlinks, you can actually view previews or specific content.
Tag Trees also allow you to create generic elements that are not normally created dynamically. For instance, on a template you might want to simulate a database by having one type of content lead only to other types. For instance, on my wiki, when viewing the Feats by Type, there are several pages. If you go to one of them, say "General Feats" it displays a table of all of those. Finally, near the bottom of the page, you can enter in a new page from the bottom and it places and tags it accordingly. However, the source for the NewPage modules are located only on the template for that category.
Creating a Tag Tree
The act of creating a Tag Tree is quite a simple process. The trick is tying your tags to the titles1 of the parent pages. Like setting a Parent, the Child may be in any category.
A Quick Example
- Create a category for your pages. We'll choose "test".
- Create your Parent page, whose title is simply Parent. You may enter whatever sample content you want.
- Create your Child1 page. Its title is Child1. Enter another simple content.
- Tag your Child1 page with "parent". The tag must be exactly the same as the title of the page you are coming from.
- Create your Child2 page. Again, some sample content
- Tag Child2 with "child1".
- Now, since we're just quickly moving along, create a Live Template for your test category.
- Enter the following code and save
[!-- This is your sample content --]
%%content%%
[!-- This looks up the pages for you.
[[module ListPages category="*" tags="+%%title%%" separate="false"]]
%%linked_title%%
%%preview%%
[[/module]]
[!-- This is your new page. --]
[[module NewPage category="test" parent="%%full_page_name%% tags="%%title%%"]]
Go to your Parent page and follow the chain. Create pages from each of your pages. You'll see that they maintain their hierarchy. Even further, you'll see that when you create pages from Child2, they will be automatically tagged with "Child2". This allows an entire chain to be created automatically. And because you are using list pages, you may show previews, format content, etc.
"Advanced" Tag Trees
Tag Trees are so simple, I'm reluctant to call these advanced, but they are more than basic. The previous example gave a hint at the barest functionality. These other types will describe different ways that they can be used.
Navigation Tree
When done correctly, a Tag Tree can help to create some minor dynamic navigation for your side or top bar. Simply use a ListPages module to refer to the navigation bar as a tag. As you add pages, they will expand. If you remove the sidebar from the wikidot category and add it yourself with an include to the content, then you can have a sidebar that changes according to the current page2. Be careful with this because unless you are managing your tags effectively, it could spin your navigation bar out of control. Additionally, if you aren't protecting your tags, you could run into serious issues with a public wiki and a lot of contributors.
Category Tree
Similar to the Backlinks approach for "soft categories", a Category Tag Tree lets you create "hard categories" by extending the functionality of the tags. The primary advantage to this over the Backlinks variant is that your pages can maintain the proper parent/child relationship and still be categorized. Another major advantage of this is that it allows you to pick and choose Wikidot categories to list from. To create a category tree, simply create a wikidot category page named category:top. Follow the example above for all sub categories. For content pages, you may add them to whichever wikidot category you want. When you tag them, simply tag them with the category you would like.
Content Trees
The section of my wiki described earlier, is a content tree. Feats by Type is a list of feats ordered by their type. When you choose a Type, it lists all of the feats of that type. And when you choose a feat, it then takes you directly to the content. This is the simplest implementation of a tree.
Tag-Tag Trees
I know. I read it too. I mean, I wrote it. I really have no other way to describe them3… On with it… If you have already implemented Protected Tags, then you have created a minor tag tree, just one that is not used as such. Using a Tag-Tag Tree4, you could easily navigate your invisible tags via ChildPages module.
Considerations
This is one area that required a lot of thinking, experimentation and work. There is no clear way for me
Advantages
- Allows for consistent templating
- Is separate from, but complements the Parent/Child system
- Does not change any basic functionality. Your tags that are not categories or parents will still work as usual.
- May be implemented as time allows, rather than all at once. For instance, you could decide to implement only your most popular tags.
- Requires very little infrastructure even for the largest tag structure.
- Allows for "multiple inheritance" or "navigation paths". That is, a child page belonging to two parents is easily possible.
- Is extensible with Multiple Word Tags and Protected Tags
Disadvantages
- Can get convoluted quickly if unmanaged.
- Inherits all of the disadvantages of Multiple Word Tags and Protected Tags as implemented with these.