Can we have a META:TOPICCHILDREN tag ?

Currently there is a tag META:TOPICPARENT so a child page retains information on its parents. What do you think of having a TOPICCHILDREN metadata item to allow a parent to keep track of its children? This would be useful for a plugin like XpTrackerPlugin that does a lot of traversal between parent and child pages, as finding children by searching for pages that match a TOPICPARENT value is just too slow.

It will also allow pages to be able to list all their children in a standardised form, probably as an option, which sounds useful.

I understand that this is not pleasing from a data redundancy perspective, and there is the danger of the parent->child and child->parent links becoming inconsistent. But since these fields cannot be directly modified by the user when editing the page, I think this should not be a major concern. It's similar to the rename page function that changes the current page but also goes through all referencing pages updating the link names, so keeping everything consistent.

-- MartinWatt - 22 Feb 2003

No opinions on this?

-- MartinWatt - 02 Apr 2003

Yes. :-)

I'd like just such a feature.

However, it shouldn't be redundant data, but should be a function of the existing topic-parent data, just as the output of %TOC% is a function of the other data in a page.

(That's not to say that the implementation might not cache (redundant) data for performance reasons.)

-- DanielBarclay - 11 Nov 2003

Suggestion: Use/Write a Plugin

I would actually propose a plugin for this. Ideally it would keep track of parent/children/refer-to/refer-by in some type of db (sqlite) utilizing the onSave hook for updating the data. It would also need some type of script that could "load" all of its initial data etc.

My $0.02

-- JohnCavanaugh - 02 Apr 2003

Suggestion: Use a METASEARCH in a skin/template

If you dont want to wait for a plugin, here is the code that will do what you want in a template.

%METASEARCH{type="parent" web="%WEB%" topic="%TOPIC%" title=""}%

For a variable in a topic itself, you would need to hack on TWiki.pm

-- JohnCavanaugh - 02 Apr 2003

Questions

Questions & Answers

Can't get METASEARCH based approach to work!

Question

• I can't get this working!
• It works here though, why? (twiki.org sandbox)
• Question echoed

Answer

The reason this works, and you're having difficulty is for the following reasons: * METASEARCH "only" works in templates, not topic text * However, if you put METASEARCH right at the very beginning of a topic, or the very end (not in the middle) this fools TWiki into thinking the METASEARCH is part of the periphery, rather than the text. * As a result the METASEARCH gets expanded.

You can see this in action if you try the following 3 URLs:

• "raw" contents of the text of the topic: http://twiki.org/cgi-bin/view/Sandbox/IanStevensSandbox?raw=1 Note the lack of the METASEARCH
• Almost completely raw contents of the topic: http://twiki.org/cgi-bin/view/Sandbox/IanStevensSandbox?raw=debug Note the clumping of the 3 META lines at the top
• However if you hit edit: http://twiki.org/cgi-bin/edit/Sandbox/IanStevensSandbox You'll see that you do have the METASEARCH line available for you to change.

Why does this work? When Twiki writes topics to disk, the end of line characters of the text of the topic are generally different from the end of line characters to the header. (At least this is true under Unix) As a result, the edit script can detect where the topic headers, and topic footers, begin and end based on this. Which is why you can edit the METASEARCH above. However the code that handles metadata seems to grab all lines at the beginning and end of a topic and uses them when do rendering of metadata.

The upshot is you can fool twiki into doing this without using a skin, but the feature (METASEARCH) is designed to sit in a skin. You could argue this is a good place for references to children to sit. You could argue it's a bad place.

Whilst it's a bug, it's a very useful one to keep around as many people have found in the past. (It's not ideal, the situation should be formalised, maybe)

With referance to the proposal above I would suggest that the idea of a plugin to do what's requested (ie a non-search based approach) is a better idea since the biggest problem the OP seems to have (?) is that the search takes too long to complete. With a large web (such as this one) this would certainly be a problem.

I personally feel however that the problem the OP is talking about is actually and optimisation one - that a search based approach would be OK if the search was fast enough. This would require a better approach to deal with how the TWikiStructure is being used.

Regarding the comment about child/parent links getting out of sync - this is a distinct possibility given that users can modify the parent of a topic already. (Just hit "more"...) This is another reason I personally feel having a TOPICCHILDREN tag isn't such a hot idea. (Even though I can think of some nice uses for it...)

-- TWikiGuest - 19 Jun 2003

Possible Other Motivations (TopicChildren == AreTopicsWebs)

AreWebsTopics discusses the idea that topics have children - the discussion focusses on the idea of attachments effectively forming subwebs, so why not allow subwebs of topics in a similar way. This discussion leads back to the argument here - a list of children would form a subset of a web (or many webs potentially) and hence be a logical web in itself. Hence topic children forms an interesting thought - if you can include a single topic or small collection of topics as children, why not entire webs?

This becomes a potential implementation idea for LogicallyNestedWebs, and impacts TWikiStructure, so I'm adding references to this topic there. (The latter is collating a number of topic children of its own) In truest form of course, I'm arguing with myself - just because you don't have backlinks, perhaps that's not a good enough reason not to allow topic children.

-- TWikiGuest - 21 Jun 2003

To give an additional reason to have topic children:

As I've argued on PleaseCreateNewWeb, showing the local tree of the topic's parent and its children gives a way to logically browse topics. It will give immediate overview of coherent groups of topics.

Hierarchical navigation is what I miss in TWiki, but is something most regular sites give you. I have implemented this in PatternSkin, but the downside of the implementation is that it is slow.

To have children in the meta data would really improve speed.

-- ArthurClemens - 22 Jun 2003

I don't agree that TOPICCHILDREN is needed, and I'm not even sure that TOPICPARENT is right either, as this information is not something that the topic necessarily knows. It may be better to maintain a file to the site that records the tree of dependencies... One organization may not be right for everyone, and different trees may organize things in different ways. To illustrate this point, right now, when you create a form, lets say there are some select fields on the form. So the form topic looks like this:

In this case, lets say the form topic is called Resource:

The Form refers to another topic called ResourceType. That file will be marked with ResourceForm as being the parent. Each option within ResourceType, lets say they are called BuyerResource and SellerResource, will show up as checkboxes on the form. Now, I want to create a topic called BuyerResource that will list all topics based on ResourceForm using a SEARCH. The parent of that topic will be ResourceType. When the search is envoked, the tree will will see in the navigation portion of the display, if it uses this information, will be showing this:

ResourceForm | ResourceType | BuyerResource

for example, which exposes the machinery of the form and the database but does little to help the user navigate.

OK, that is a simple example of when the current setup works non-intuitively. In general, there may be a need to express a different heirarchy than originally envisioned by the author of the topic. You can't do more than one heirarchy at a time if this information is embedded in the topic. Therefore, I think the TOPICPARENT approach, when embedded in the topic, is not a powerful architecture. A separate means to construct heirarchies is probably better.

After sleeping on my comments above, I realized that the TOPICCHILDREN tag is really not a problem as it is redundant with the information already in the topic, if you assume that all child topics will be referenced in the current topic. That means we are only summarizing the information at the top of the topic for ease of generating heirarchical navigation trees. That is fine. The TOPICPARENT tag is a bit more of a problem.

With all this said, I am in favor of the TOPICCHILDREN tag to ease processing in creating the topic trees.

-- RaymondLutz - 12 Nov 2003