Item3599: All plugins shipped with TWiki should make use of registerTagHandler(), lazy compilation and delayed initialization

Here's a quick summary of the code quality in standard plugins shipped with TWiki:

	registerTagHandler	lazy compilation	comment
CommentPlugin	no	yes
EditTablePlugin	no	yes
SpreadSheetPlugin	no	yes	we will no longer need to list it in PluginsOrder as a consequence
EmptyPlugin	both	no	this needs a recoding to illustrate lazy compilation
InterwikiPlugin	can't	no	but its init can be delayed
PreferencesPlugin	no	no
TwistyPlugin	yes	no	and delay some stuff in init
RenderListPlugin	no	no	uses deprecated startRenderingHandler
SlideShowPlugin	no	yes
SmiliesPlugin	no	no	smilies themselves can't be handled by the registerTagHandler, but the seldomly used %SMILIES% tag initialization should be delayed
TablePlugin	no	yes	some init code in commTagsHandler can be delayed further
WysiwygPlugin	yes	partially	the WysiwygPlugin.pm has +500 lines of code alone

Lazy compilation should be refactored for EditTablePlugin, SpreadSheetPlugin, EmptyPlugin, SlideShowPlugin, and the others in a standardized way as much as possible.

As a rule of thumb, the trade-off between delayed compilation and higher IO reading more pm files is ca at about 300 lines of code in the main plugin pm file, including comments. For example, the WysiwygPlugin has more than 500 lines of code in the WysiwygPlugin.pm file. So this indicates that code in there has to be analyzed if it is possible to delay its compilation. In the end most of it is not needed during a normal view and only during edit and save.

Using registerTagHandler for SpreadSheetPlugin comes with a little danger that this will break existing TWikiApplications, because it will be evaluated in the round dance of all other plugins that correctly use the registerTagHandler now. These tags are currently evaluated even before %CALC% and even though the SpreadSheetPlugin is listed first in PluginsOrder.

Another advantage of the plugins, i.e. the SpreadSheetPlugin, to be brought to Dakar standards is that it will be accessible inside %IF% then (hm, not sure if this is not the case already).

-- MichaelDaum - 10 Feb 2007

I do not think it is possible to refactor EditTablePlugin, RenderListPlugin, SlideShowPlugin and SpreadSheetPlugin to use registerTagHandler since those plugin manipulate topic text outside the %VARIABLE{}%, and registerTagHandler only provides the parameterstring of the variable.

-- TWiki:Main.PeterThoeny - 10 Feb 2007

The plugins order needs to be retained. For example, to make sure that CHART is evaluated after CALC. Those tags are not nested; the CALC is referring to a table that contains CALC.

-- TWiki:Main.PeterThoeny - 10 Feb 2007

I removed EditTablePlugin, RenderListPlugin, SlideShowPlugin and SpreadSheetPlugin from the Component list, they clearly cannot use registerTagHandler.

-- TWiki:Main.PeterThoeny - 09 Mar 2007

Knocking off WysiwygPlugin as well. The bulk of WysiwygPlugin.pm is comments, and I really don't think there is anything to gain by lazy-compiling what remains. CommentPlugin is also as lazy as it needs to be, and can't use a tag handler (it numbers the comments sequentially in the topic).

CC

%22Removing%20InterwikiPlugin%2c%20SmiliesPlugin%20and%20TablePlugin%20from%20the%20list.%20The%20former%20two%20have%20a%20special%20syntax%2c%20e.g.%20you%20can

-- TWiki:Main.PeterThoeny - 12 May 2007

I just had another case of Item4028. This is what I wanted to post:

Removing InterwikiPlugin, SmiliesPlugin and TablePlugin from the list. The former two have a special syntax, e.g. you can't register a %SOMEVARIABLE{...}%; the latter manipulates content outside of the %TABLE{...}% variable.

-- TWiki:Main.PeterThoeny - 12 May 2007

Accidentally attributed a checkin 14536 to this topic that applies to Item4028.

CC

Seems to be dealt with

MD