Question

I'm posting this because of a saying that goes something like "three months in a lab will save you three hours in the library." I want to get some feedback from more experienced developers before I start working on this- so it's not really as much a code question as it is about what tools should be used.

I'm currently working on a database application, wherein the data stored takes the form of a tree. For example:

China
    Economics
    Stat 1
        Pre Cultural Revolution
            Stat 1
            Stat 2
            ....
            Stat 101
        Post Cultural Revolution
            Stat 1
    Natural Resources
          Coal
              Stat 1
           Oil
              Stat 1

Japan
      (ETC ETC)

A user should be able to go to a webpage with a bunch of dropdown forms (self-populating) and select CHINA -> NATURAL RESOURCES -> COAL and see stats for that. Or they would be able to search for "CHINA NATURAL RESOURCES COAL" and get a webpage with the results. Users should also be able to insert mostly new statistics and, very occasionally, a new category.

I've been thinking about how to go about doing this, and I'm hoping that I can get some feedback from some more experienced developers.

One idea I have is to use TWiki's built in parent/child feature, and just build the tree that way. Because of how the users want the database set up, I won't use WikiWords for topics (the topics would be similar to what you see above).

One problem with this approach is that it's anti Wiki: we mostly want users to use the Topics that have already been defined- we really don't want users creating a lot of their own parent topics (that is to say, users just create leaves, and not branches). Occasionally, a user might might need to create a new branch- but we would want this interface SEPARATE from how they would add a new statistic (leaf). That is, when a user creates a new topic, they're actually just creating a new statistic . If they want to create another category (branch), they would have to do this on a different page. In this way, the process for creating categories and statistics is separate.

Another problem is that the names of categories and statistics wouldn't be WikiWords. That is, we might want names like "Energy Use Statistics" and not "Energy Use Statistics" (this is my boss's requirement). I know that TWiki can use non-wikiwords, but as far as I know, it deletes spaces and runs the words together. Is there a way around this?

The other idea I have is to just make a bunch of topics, and ignore TWiki's native parent/child relationship thing. Instead, I would just make use of forms and try to do things via metadata. I would do this either using the DBCachePlugin? or the FormQueryPlugin? .

But at this point, it seems like I might as well just code my own thing in Ruby on Rails or PHP. Seems like too much work for something that has certainly been done many times before!

I'm worried because the requirements of the project make the whole thing feel very kludge-y. I know that parts of the project are anti-wiki, but I know that TWiki has a lot of flexibility built into it, and I'm hoping to take advantage of that.

Any thoughts?

Environment

-- MaxPar - 08 May 2008

Answer

If you answer a question - or have a question you asked answered by someone - please remember to edit the page and set the status to answered. The status is in a drop-down list below the edit box.

> might want names like "Energy Use Statistics" and not "Energy Use Statistics"

I assume you meant, might want names like "Energy Use Statistics" and not "EnergyUseStatistics".

Would the boss go for an underscore (instead of SPACE) in the topic name? Those aren't WikiWords either and so aren't automatically linked, e.g., Energy_Use_Statistics, so you need to use forced links, e.g., [[Energy_Use_Statistics]]. You also want to force the link because it would otherwise be displayed strangely at times (e.g., with spaces, when used in a section header). But at least the underscores aren't deleted.

Of course it would be easier in the long run if you use WikiWord names. Maybe he'd go for that if you pointed out that you could still display the names with spaces (e.g., in your site map) using the SpreadSheetPlugin's PROPERSPACE function (with a DONTSPACE list to suppress that spacing where required, e.g., MacDonald? , ActiveX? ).

On the layout, I prefer your first idea, of using the built-in parent relationships for topics. TWiki will take care of a lot of maintenance for you, such as when (not if) you want to move or rename branches. And then you can use a nested search to build a site map just like the one you showed.

For the nodes on the tree, take a look at TWikiTemplates, specifically the sections "Automatically Generated Topic Names", and "Template Topics in Action". That could give topics with names like Stat_001. And the interface to create a leaf would definitely be different from the one to create a branch.

P.S. notice that Stat_001 wasn't linked above, because I didn't force it, like so: Stat_001? .

-- SeanCMorgan - 08 May 2008

You're right about it being "EnergyUseStatistics" and not "Energy Use Statistics."

I had no idea that the PROPERSPACE() function existed, but I think it would work quite well for what I'm doing. Thank you for telling me about it- I never would have looked in that plugin for a function like that!

The nested search from the FormattedSearch? would work well, and I know that I can do something similar to that using FormQueryPlugin? .

With regards to building a search where a user can select branches from a self-populating drop down box: How do you think this could be built? I guess feeding a nested search's results into a dynamically generated form would be the most straightforward way to do it.

Thanks for your help with this!

-- MaxPar - 09 May 2008

I read carefully your problem, and I think, besides look strait forward the implementation, you should consider those points that constraints what we call a tipical TWiki data base application:

• In thinking of the data in a twiki aplication, you are mostly concerned with topics that has a form associated with. What actually is in a topic is a Twiki user concern, that is, is important people of your organization follow the rules you stabilished in order to not break your twiki app. So whatever you go throw your first or second idea, consider if people of your organization could go easily with your stabilished conventions.
• In doing a search, you must pay attention of what kind of searchs twiki can perform with realatively easy. And that is limited by %SEARCH% variable and can be extended with those cited plugins.
• And, last but not least, I feel you have the right concerns of how to structure an application trying to keep the wiki approach, in other words, trying to understand the wiki philosophy and its gold rule: everyone edit everyone's topic, with minimum possible restriction

Now I setup those considerations, I actually tried to implement a prototype at my own twiki, so bellow are the link to the main Application (a good pratice when making a Twiki Application), feel free to check there, but unfortunatelly I run also this twiki in my own computer since I'm a student that uses it alot maybe it can be slow. I hope that can help you.

• http://marcowiki.no-ip.org:1050/cgi-bin/twiki/view/Sandbox/TWikiAppExample

-- MarcoSilva - 09 May 2008

Marco,

I've been trying to get to your wiki for the past day, but it hasn't been up. Is there anyway that maybe you could send me the code, so that I could take a look at it?

-- MaxPar - 10 May 2008

Sorry, it was really down yesterday, so I packed it up here the set of topics.

-- MarcoSilva - 11 May 2008

Thanks for the example, Marco. I'm going to mark this subject as answered!

-- MaxPar - 11 May 2008

>With regards to building a search where a user can select branches from a self-populating drop down box: How do you think this could be built? I guess feeding a nested search's results into a dynamically generated form would be the most straightforward way to do it.

I have an example a dynamically populated dropdown on my user topic (the section with the Action Tracker form). In that example, it uses a list of user topics.

P.S. with the Query search in TWiki 4.2, you probably don't need FormQueryPlugin any more.

-- SeanCMorgan - 12 May 2008