Pattern skin loads TwistyContrib's css and js by default. But when TwistyPlugin is enabled, both files are added to the head to load as well. And both additionally load twiki.js. See
Item1653.
This seems a lot of overhead.
In the meantime, the plugin 'head handling' has been cleaned, so that now TwistyPlugin only is loaded if there is a TWIST tag on the page.
Proposal: make the whole thing leaner and cleaner by making pattern skin rely on TwistyPlugin. Some refactoring is needed to convert the current html twisties to
TWISTY
tags.
There is an enormous optimization possible: since TwistyPlugin knows about the TWISTY tags on the page, it can generate javascript to directly address the html elements to be shown/hidden- instead of the current slow approach of scanning the page looking for possible tags.
Disadvantage: a user might disable
TwistyPlugin in configure, and a lot of TWISTY tags will show up.
AC
The gain is hight the loss marginal if there at all. I'd say go for it
MD
Now that I've rewritten TwistyContrib with speed gains, and optimization for TwistyPlugin is no longer seems necessary, I found two more motivations to let pattern skin use TwistyPlugin:
- TwistyPlugin js is now a singleton class; importing the js file twice will also invoke the singleton constructor twice (so all UI elements will be registered twice and so on). This defeats the speed gain.
- Any changes to the plugin css/div/span layout need to be handcrafted through all of pattern skin templates. Wouldn't have been necessary with
TWISTY
syntax.
AC
Done. See
TwistyPlugin for the latest additions.
AC
4.1.0 released
KJL