This idea has been hinted at by several people, several times. Due credit to them.

At the moment, TWiki relies on a "standard" syntax for expressing meta-data (such as searches or plugins tags) embedded in text:

meta-tag ::= "%" tagname [ "{" attr-vals "}" ] "%" ;
tagname ::= m/[A_Z]+/ ;
attr-vals ::= attr-val [ attr-vals ] ;
attr-val ::= string | id "=" string ;

Plugin authors of course try to follow this syntax when writing their plugins, with varying degrees of success. The problem is there are few rules for use of the syntax, and the plugins API doesn't provide any standard method for extracting and processing parameters. There are no standards for escaping characters, and the RE's to unpick this mess often get very confused. Also, the widespread use of the $text =~ s/%MYTAG{(.*?)}%/ makes introducing an alternative, less convoluted, tag syntax impossible.

What would be nice would be to have a standard tag parser that was able to extract and parse those tags from the text and apply a callback. The plugins interface could provide a function like this:

processTag($text, $tagName, $callback, ...) -> undef

where $tagName is the name of the tag e.g. MYTAG and $callback is defined as:

callback(%params, ...)

where ... is the same ... as passed to processTags. %params would be a hash filled in by parsing the parameters to the tag (empty if there are none) according to a standard syntax specification. FWIW the Attrs.pm module (shared by all my plugins) already provides such a standard attributes parser.

-- CrawfordCurrie - 28 Mar 2004

This is related to EnhancementsToThePluginAPI suggesting that Plugins declare their tags. If done right it could improve the performance

This is because only one regex can handle all registered Plugin tags, e.g. called by s/%[A-Z]+{(.*?)}%/handleRegisteredPluginTags/ge. It is somewhat tricky to get the Plugin execution order right as defined in the Preferences.

Also related is FunctionToExtractAllParameters.

-- PeterThoeny - 28 Mar 2004

I think you are maybe missing the point here. The proposal is not to pre-register tags handled by the plugin; the proposal is to abstract out the parsing of the syntax of a plugin tag so the plugin author doesn't have to handle it. There's no impact on the execution order.

Note that I have assumed that the order in which tags in the text are processed would be consistent from run to run viz. The first occurence of the tag would be processed first, the second second, and so on.

It occurs to me that there needs to be a companion function, generateTag($tagName, %attrs), that regenerates the original syntax for the tag. This would be required by any plugin that generates syntax, such as the ActionTrackerPlugin.

See attached code for a full implementation.

-- CrawfordCurrie - 29 Mar 2004