Feature Proposal: Extended handling of variables to improve wiki database use

Motivation

From the point of view of some (many?) users the use of preference settings is hampered due to the fact that wiki wide preference settings can only be set in the preferences topic and that there is no way to read or write preference settings in topics. Therefore I wrote the VarHandlePlugin to circumvent this weakness.

As outlined in Tasks.Item174 I am happy to share this feature and have it integrated in the core.

PLEASE: Read everything carefully and make sure that you understand the intentions of this feature, before you raise any concern (see also: Community.ProjectCulture. Ask questions, If something is not clear. Use the discussion area for comments to keep comments trackable and readable for other users!

Description and Documentation

The new core extension feature will allow users the following options (provided the have VIEW and CHANGE Access to the topic the address):

1. Read the value of a known preference setting in any topic in any web (either in text or meta data)
   • This is already available for webs using the %VAR macro (of %META for meta-data)Yes, but this would enable you to read every variable in any topic everywhere your Wiki!
2. Write a new value of a known or new preference setting in any topic in any web (either in text or meta data)
   • This sounds exceptionally dangerous from a security perspective. When is the write done? When the topic is viewed? It is not dangereous at all (see comment below in discussion). It will be written, when the topic is saved and can be removed automatically after writing (remove="on")!
3. Transfer a text preference setting into meta data
   • A reasonable thing to want to do :-)
4. Read certain values of metadata of any topic (especially from FIELD metadata)
   • This is the same as 1, isn't it? No, 1 is for preference variables only. This returns values of all metadata (ATTACHMENTS, TOPICPARENT etc.)
5. Write certain values in metadata of any topic (especially from FIELD metadata)
   • Same concerns as for 2 No, see above. E.g. you can write a new comment for a certain attachment!

Examples

There are far too many possible variations to list them all. Thus just a few examples, how flexible and powerful the new function is:

• %VARHANDLE{topic="WebPreferences" web="Home" name="SKIN" value="pattern" mode="write"}%
  • writes the new value pattern into the topic and thus changes the skin of the whole web

• %VARHANDLE{topic="TestTopic" web="Home" name="TEST" mode="read"}%
  • returns the value of the variable TEST (empty, if not defined) of the topic TestTopic (eithe meta or text)

• %VARHANDLE{topic="WebPreferences" name="all" value="pattern" replace="yes" mode="convert"}%
  • converts all text variables in WebPreferences into meta preference variables and deletes the variable in the text.

• %METAHANDLE{topic="SampleTopic" name="ATTACHMENT" name="test.file" value="Sample comment" focus="comment" mode="write"}%
  • Write the value into the meta attachment data of SampleTopic

• %METAHANDLE{topic="SampleTopic" name="FIELD" name="Postbox" mode="read"}%
  • Returns the value of the FIELD Postbox

• %METAHANDLE{topic="SampleTopic" name="FIELD" name="Postbox" value="2009" mode="write"}%
  • Replaces the actual value of the FIELD Postbox by the new value 2009

• %METAHANDLE{topic="SampleTopic" name="FIELD" mode="list"}%
  • Lists all FIELD metadata of the SampleTopic

• %METAHANDLE{topic="SampleTopic" mode="list"}%
  • Lists all metadata of the SampleTopic

Impact

• Makes the FORMFIELD and some other variables redundant

• Makes the use of the wiki database feature (Form, Field, Template) far more powerful, since all datas can be read and written from anywhere in the wiki

• Makes SEARCH far more powerful, e.g. you can query all topics in web containing a certain field and then print the value in a list at the same time).

• Using this feature in templates create a lot of new opportunities (e.g. show content depending on values of certain variables in certain topics).

WhatDoesItAffect:

%WHATDOESITAFFECT%

edit

Implementation

-- Contributors: WolfMarbach - 16 Nov 2008

Discussion

I'm unclear exactly what you are proposing here. I took the liberty of removing "variable" above using the TWikiTerminologyMap, because I was getting confused by "meta variable" and "text variable" but I'm still confused (hope I got the mapping right). I added some notes to try and clarify.

mode="read" With regard to reading preference values from other topics (as against webs) there has been a feature request open for some time for this (see MakingVarVARTopicCapable). I agree that this would be a useful feature, but the fact that no-one has stepped up to do it makes me wonder if others see it that way. For meta-data it is IMHO unquestionably useful, but should be done through the existing %META macro.

mode="write" Obviously you can override preferences in a local topic by the simple expedient of defining them:

   * Set PREFERENCE = value

and as long as the value isn't finalised, it will apply whenever that topic is viewed/edited/whatevered. I would consider the ability to change preference settings from "a different place" (i.e. not from an edit of the topic that contains the setting) as exceptionally dangerous and hard to control, if that is what you are proposing. For meta-data values this may be potentially useful, but is fraught with potential risks regarding the typing of data values and access controls. It would require very careful design.

mode="convert" I'm not quite clear on what the value of this actually is. As for mode="write" of preferences, I think it would be very dangerous to allow this to affect a different topic. If it only affected the current topic, then it's a "one-shot" function. But when is it executed? When the topic is saved? When it is viewed? Every time it is viewed?

mode="list" This is something that may be useful for preference settings, via %SEARCH. For meta-data it obviously already exists (via SEARCH).

Finally, I don't find the names VARHANDLE and METAHANDLE in the least bit intention-revealing (I never liked %VAR either, and I suspect the name is one reason you maybe didn't find it)

So, maybe I understand what you want, maybe I don't, but if I do then I think what you have here is an excellent review of what's missing from the existing macros. I think what you want needs to be addressed by extending the %VAR and %META to support specification of a different topic, and the %SEARCH macro to support a type="preferences". I think the writing of preferences in a different topic is potentially dangerous and would need to be designed extrmely carefully to address security issues. I think the writing of meta-data in a different topic is potentially useful, but I am unclear as to when this write would occur.

-- CrawfordCurrie - 18 Nov 2008 - 07:45

Thanks Crawford for your detailed comment! I will try to answer your remarks:

• text variable means a variable defined in the topic-text (e.g. * Set SKIN = nat). meta variable means a variable of the %META:PREFERENCE type.

• mode read: perhaps some people do not see the value, since they don not understand the implications. The name of the new function doesn't matter.

• mode write: the value will be written when topic is saved and can automatically be removed, so that it won't be executed once again. This is not dangerous at all, since the plugin checks the access rights and only allows write when the user has VIEW and CHANGE right. Thus there is no difference to what he can do anyway. The user just does not have to go to the topic, but can do it remotely.
  • Remark: Please do not drum the dangerous and security drum. One the one side people tell me that wiki culture is being open, thus I got the impression that access rights is just something they have to bear ( AccessRightsChange). On the other people are concerned about security. I do not understand that. If a user has access to edit a topic, why should he not have the right to change a value remotely? There is no difference as long as access rights are checked accordingly.

• mode convert: For me (and some other people) it is sometimes confusing that there are preference variables in topic text and in topic meta data. Especially when the same variable is set in both (e.g. I got once crazy with the WebPreferences plugin) With convert you simply transfer variables in text into meta preferences. This would allow you to easily revise the whole WebPreferences setting in a simple but professional way (but that is another story).

• mode: list makes things much easier than search

• names are smoke and mirrors, just suggest something you like better

• extending var and meta not sure, if that complicates some matters, but certainly is an option. security see above. writing occurs only and while saving (if you want to write it with each topic view you choose remove="off")

-- WolfMarbach - 18 Nov 2008

If I understood correctly, the main use I see for mode write is to quickly script some maintenance task and to allow (WikiApplications?) to update data in topics without using a plugin.

The ability to set a preference or a meta field in another topic with mode write is secure enough as long as the user is allowed to change only what he can change (ie, has ALLOWTOPICCHANGE permission on the target topic). This may, or may not, limit the usefulness of the feature for applications.

But I think that feature is dangerous, as a badly-built SEARCH can destroy your data.

As for the rest of the functionality, it would be a very welcomed extension. If VARHANDLE and METAHANDLE are implemented as extension of the VAR and META syntax, it would be even better.

This is a prime example of a feature that could be implemented first as a Plugin and then, when the syntax is hammered down, integrated into the core (if needed/wanted)

-- RafaelAlvarez - 18 Nov 2008 - 21:39

Flipping this to ParkedProposal. It's been 3-1/2 years without any activity. In the meantime we have the MultiTopicSavePlugin that sounds as though it can accomplish some of this.

-- GeorgeClark - 23 Feb 2012