Feature Proposal: Bring TopicVars into Core

Motivation

I am proposing to add Plugins.TopicVarsPlugin's functionality to the Core. While building TWikiApplications I've worked with pleasure calling variables from one topic (and web) into another, and I've even come to rely on it. It is a great help in creating usable interfaces.

Although some plugins share similar ideas, I haven't found this pure functionality elsewhere. It seems so natural that I have wondered why this is not part of the TWiki codebase. It would be an easy fit with other TWikiVariables.

-- ArthurClemens - 15 Jul 2005

Discussion:

I agree.

-- MartinCleaver - 15 Jul 2005

I can see how that makes sense.

Perhaps you could also illustrate some applicaitons using this. Examples are always good!

-- AntonAylward - 15 Jul 2005

One example I can give is an extranet where each client has his own restricted web area (a good example of webs!). The web name is just a web name: soe sort of WikiWord, so nut useful because it heavily mutates the client's names. A client like GSK doesn't want their name written as Gsk in each and every window title or in the breadcrumb. TPG Post TNT wouldn't want their name as Tpgposttnt or as TpgPostTnt.

So I use WebPreferences to set a few variables, one of them is the client's name. Now I can use %WEBPREFSTOPIC%.%CLIENTNAME% to write the name in the window title. And I use it with site wide search to create a list of all clients. I link to each WebHome, but the link label is each client's name.

Each client can have one or more projects. So with the same idea I create project sub-sites. Each project has a decent name of course to use in window title, breadcrumb and project listings.

The same goes for client logos (CLIENTLOGO variable). On an admin page I can create an overview of all client logos so I can see which logos still have to be uploaded, and if the sizes match.

I also create admin pages with custom .htaccess texts created for each client, to help the system adminstrator secure the site. Of course you can select clients using a dropdown box, with the proper names in there.

As you can see, the topic vars syntax just blends with the TWiki variables syntax. Very intuitive to use. Its like OOP programming.

-- ArthurClemens - 15 Jul 2005

It looks like it is related to ContentAccessSyntax, which is a major enhancement I'd like to see in DakarRelease.

-- PeterThoeny - 16 Jul 2005

It would indeed be nice to have this in Dakar. This has to be designed carefully, and implemented even more carefully.

On the syntax front, there needs to be a generic variable access syntax, which is extendable inthe future to support concepts such as access to containers (arrays, hashes). On the implementation front, it could be hacked in easily enough, but it would probably foul up the code architecture even more that I already have done

I was reluctant to move forward with ContentAccessSyntax until we have the TopicObjectModel in place. We're getting closer to that, but there is still a way to go. For example, preferences are still handled completely separately from topic text, which is handled separately from meta-data. These concepts all need to be rationalised to be able to do this sensibly (without just hacking it in).

I'm not saying it can't be done; I'm just saying I question whether it is appropriate for DakarRelease, as it would delay that release even further to do this properly. And after all the effort I have put into cleaning up the code, I am very keen that it should be done properly.

Having said that, design a good generic, clean, unambigous syntax, and we can probably address at least a subset of it in DakarRelease.

-- CrawfordCurrie - 16 Jul 2005