Most Plugins defined some %name{...}% variables. If I understand it right, this means that for any such variable replacement the whole text has to be searched using different regular expression.

• Well, sort of. Actually there is a method TWiki::Func::extractNameValuePairs, but we made a few mods to it. -- MartinCleaver - 15 Nov 2001

I didn't measure if this is a problem, but wouldn't it be better parse these variables in one place (/%[A-Za-z...]{...}/) and let a plugin register it's variables? This would also have the advantage of a general argument parsing facility (for what's inside {}). Maybe there would be a need for priorities and such.

• Agreed that Plugins should register (or request) variables. IMHO it could be like the Exporter method in Perl. -- MartinCleaver - 15 Nov 2001

Considering the prerendered topic above, the prerenderer has to leave some variables unreplaced (such as searches, which are by nature not static). This surely introduces some more complexity.

-- MichaelUtech - 14 Nov 2001

(Perhaps we need a new TopicClassification for Codev - something like SuggestedCodeImprovements? ?)

-- MartinCleaver - 17 Nov 2001

I think this may also help with the impending problem of variable pollution. I can see a problem of people producing different plugins that use the same variable names for different purposes in different plugins. Perhaps plugins should only be able to register %PLUGINNAME:VARIABLENAME{PARAMETERS}% by default, and need configuration settings in TWikiPreferences? for using variables not qualified with the web name.

-- MartinCleaver - 17 Nov 2001

Plugin variables are pre-registered by the Plugin handler, so they are fast. I.e. if a MyPlugin defines a Set SUSHI = great taste you can access it in any topic with %MYPLUGIN_SUSHI% and programmatically with TWiki::Func::getPreferencesValue( "MYPLUGIN_SUSHI" ).

If you need several name="value" pairs you can define a separate Plugins setting for each pair. Alternatively you could define one Plugin setting, i.e. Set SUSHI = taste="great" size="small", get the whole preferences value, and finally extraxt the name/value pairs with TWiki::Func::extractNameValuePairs().

-- PeterThoeny - 18 Nov 2001

Hi Peter, it wasn't this sort of variable that we were talking about. We were talking about the kind of variables that a plugin may offer for substitution, for instance the SpreadSheetPlugin adds the %CALC{} % variable.

I was therefore concerned about plugins polluting the variable space.

-- MartinCleaver - 18 Nov 2001

I think that some name clash is inevitable if you want to keep the text as simple is possible ...

-- AndreaSterbini - 18 Nov 2001

I don't think that any of our two issues, performance and namespace is crucial, but then since registering these vars offers both at the cost of nothing, still I think it would be good to have it.

Or am I wrong that for each plugin and then for each "variable" the whole %TEXT% has to be s///'ed? If so, then having plugins register there var's would require one s/[a-z]*{}// and then a hash lookup for $1 to find the plugins handler. Right?

-- MichaelUtech - 18 Nov 2001

I agree with you Michael. I think you could make a hash of pointers to functions and index straight from the function name.

-- MartinCleaver - 23 Nov 2001

I have finally got your point .... that's a very very good suggestion, both to simplify the developement of new plugins and for automatically generating a Syntax table for documentation purposes.

-- AndreaSterbini - 24 Nov 2001

See PeterNixon's comments in EnhancementsToThePluginAPI for a sketch of a solution.

-- PeterKlausner - 08 Jul 2003

Registering tag handlers for plugins can be implemented in 6 lines in FuncDotPm if the LocationLocationLocation change is merged.

-- CrawfordCurrie - 28 Oct 2004

This topic needs to be refactored, the feature was implemented in DakarRelease.

-- PeterThoeny - 21 Oct 2005

Nah, just marked as implemented.

CC