NOTE:	TWikiTags have been renamed to TWikiFns to avoid confusion with the term "tag" related to folksonomy

TWikiTags - background, benefits, and impact on 4.1

Background

NOTE: This is nothing to do with Web 2.0 / blog style 'tags', as implemented in TagMePlugin.

As of Dakar, it became possible for plugins to associate a tag with a function, via TWiki::Func::registerTagFunction. At the same time, most TWikiVariables became associated with the function that implemented them in the same way, although the code for all of these was contained in the module TWiki.pm. Every TWikiVariable was associated with its function, and every function was compiled every time TWiki.pm was compiled.

At some point not too long after Dakar shipped, the following changes were made in the =DEVELOP=branch:

1. The code for most of the TWikiVariables was moved into individual perl modules, one per variable
2. A function was added that would load and compile the code as needed
3. Any module FOO.pm in the Tags directory would work in the same manner. That is, if %FOO{arg1="blibble" arg2="glibble"}% were encountered, FOO.pm would be automatically loaded and the call replaced with the resulting text.

Anyone who has used the DEVELOP branch has been using this changed code without even noticing it. At least one site has been using this code for production purposes.

Benefits

Usability

Pluggable tags are a major plus for plugins authors. They are much easier to create than a full-blown plugin; thus, with proper documentation of TWikiTags development, there may be a large influx of helpful tags which will make it easier for users to do things without learning esoteric recipes. It also allows using many small tags with no performance hit. This make it much easier for the users to do things that ought to be simple, but currently involve complex searches or other machinations. For example:

• • ChildTopicsTag - just put %CHILDTOPICS% into a topic and it creates a (by default) bulleted list of child topics
  • ImgTag - Not only removes the need to put HTML img code in, but allows for captions to be associated with an image
  • TitleTag - really for use in skins. Currently allows specifying things such as "spacify"
    • TitleTag points to placeholder "Empty TWiki Tag" page. -- ArthurClemens - 28 Jun 2006

Performance

As noted above, code for TWikiVariables that aren't used in a topic isn't loaded or compiled. As most of these functions are not very large, this probably doesn't have any significant performance benefit at this point. However every full-blown plugin has a performance impact -- a Plugin object is created for each plugin and the code for each plugin is checked for handlers -- although it's unclear at this point how much of an impact each has. Since by definition TWikiTags have less impact, sites can use them without concern about performance costs.

Flexibility

Individual TWikiVariables can be extended without changing TWiki.pm. For example, the DEVELOP version of METASEARCH has the more useful parameters of SEARCH added to it

Refactoring

By splitting out tags from TWiki.pm we lighten that horrendous module, as well as laying necessary groundwork for pluggable tags. The advantage of pluggable tags is the ability to extend/modify the function of the preprogrammed tags, and create pluggable documentation. For example, Meredith has added the more useful SEARCH arguments to METASEARCH, making it much simpler for people to do searches. Since the code for the METASEARCH tag isn't part of TWiki.pm any more (in =develop+) but is, instead, a pluggable tag, she was easily able to extend the functionality.

Impact on 4.1

Other than one change that I would like to see made, the code is written and working already. All that remains to be done is to write unit tests. If there are unit tests for the current TWikIVariables, this should be trivial (at least for those who comprehend unit tests).

There are several TWikiTags that have been written and are being used. For example, CHILDTOPICS lists the topics that have a given topic as its parent. There are probably a number of complex idioms -- mostly searches -- that could be turned into TWikiTags, allowing easier authoring.

-- Contributors: MeredithLesly, CrawfordCurrie

---

Discussion

For the most part, the original reason for this work was published as "performance", and there may indeed be a performance gain from being able to drop the plugins infrastructure for those plugins that simply publish tags, and from being able to compile tags on demand instead of always. Personally I would like to see performance numbers before committing to a decision.

-- CrawfordCurrie - 05 Jul 2006

It definitely would be good to have some numbers.

I never thought there would be a huge performance gain from this, so that wasn't my original reason. The other benefits were my raison d'etre. For example, I considered it a major benefit to be able to extend METASEARCH (and a couple of others) without changing TWiki.pm.

-- MeredithLesly - 05 Jul 2006

See also the discussion on TagsAndMacrosDiscussion about the trade-off extending TWiki using perl versus pure TML.

-- MichaelDaum - 05 Jul 2006

The discussion is useful. There isn't, however, a tradeoff in that they are not mutually exclusive. In some cases TWikiTags make sense; in other cases, included snippets make sense. Currently we don't have macros in any meaningful sense, as noted in the discusssion.

-- MeredithLesly - 05 Jul 2006

Hm, when I created the BlogPlugin and the DBCachePlugin I took much care deciding what to cast in perl and what to do in TML-land. There is a tradeoff and maybe one will have to find out him/herself while doing TWikiApplications. Infact macros are even more important to TWikiApplications as the tags they use. For example the TWikiWorkbench approach basically is the concept of a TWikiApplication to write large scale TWikiApplications. At its core it standardizes TopicFunctions (aka macros) and TopicTypes and facilitates managing them efficiently.

We do have parametrized INCLUDE/DBCALLs released into the world for quite some time. TWikiTags are not. So why do you think that we don't have macros in any meaningful sense?

-- MichaelDaum - 05 Jul 2006

Parameterized includes are not the same thing as macros. They may be the closest we have, but they're not macros IMO.

I do, in fact do use paramaterised includes in my current project, having created a Lib web to put them in, so I'm certainly not opposed to them.

At any rate, it's still not a vs. Snippets to be included have their place as do plugins/tags. I've never said that tags take the place of all snippets. But you can't write a better version of METASEARCH using macros.

• Why? Last time I looked METASEARCH was calling SEARCH but casted in perl -- MichaelDaum - 05 Jul 2006

-- MeredithLesly - 05 Jul 2006

But I said lots of your tags can be done using snippets.

-- MichaelDaum - 05 Jul 2006

Other than ChildTopicsTag, which could be done with a PITA SEARCH, which ones do you think can be done using snippets?

I don't quite get why you seem to be arguing against using tags. I'm certainly not arguing against using snippets.

-- MeredithLesly - 05 Jul 2006

I argue for a more sensible balance between plugin/tags and snippets.

-- MichaelDaum - 05 Jul 2006

More sensible than what? And this doesn't really go here, since the issue being discussed here is using tags instead of plugins, not tags/plugins instead of snippets.

-- MeredithLesly - 05 Jul 2006

I realise this is already coded, but could we please change the name from TWikiTags? 'Tagging' is a well known concept in the blog and Web 2.0 world, and even implemented in TagMePlugin on TWiki.org, so it's very confusing to have this concept re-used for something entirely different within TWiki...

-- RichardDonkin - 05 Jul 2006

The word "Tag" is used in many ways including, of course, HTML, which well precedes blogging. I am loathe to change something that has considerable code already implemented, but if you can come up with a short meaningful word instead of Tag I'd be willing to consider it. (TWiki uses "tag" in its code to refer to these entities, which is why I chose the name, in case you were wondering.)

-- MeredithLesly - 05 Jul 2006

Can this topic text be reduced to a gateway (disambiguation) topic? Move relevant content over to TWikiFns, and replace the content with a bullet list to topics about "tags" of different meanings.

-- PeterThoeny - 18 Jul 2006