• Do not register here on develop.twiki.org, login with your twiki.org account.
• Use View topic Item7848 for generic doc work for TWiki-6.1.1. Use View topic Item7851 for doc work on extensions that are not part of a release. More... Close
• Anything you create or change in standard webs (Main, TWiki, Sandbox etc) will be automatically reverted on every SVN update.
Does this site look broken?. Use the LitterTray web for test cases.

Twisty javascript now uses getElementsByClassName, which is dead slow on IE. To gain speed we would need to use getElementById. But how can the script recognize the ids in the onload function? For this we need the TwistyPlugin to create a javascript array of ids.

This also means that pattern skin no longer only needs TwistyContrib, but also TwistyPlugin. Not a real problem I think, as the real overhead is in the contrib, not in the plugin.

AC

Without analysing your code it's impossible to work out what you are trying to do; could you please add some explanatory comments? twiki.js was equally obscure, though I added some comments in SVN 7674.

One observation is that you only ever apply the twistyMake classes to divs. You could formalise that limitation and getElementsByTagName("div") instead, which would significantly reduce the number of elements you have to iterate over to find the classes.

It's not immediately clear to me why you do this huge iteration anyway, as you could equally apply the twistyHidden class on the element in the template, in most cases.

CC


Note that I did not write the plugin. I have only added to the contrib js.

I have understood that Twisty (plugin) can be applied to spans as well - this is a parameter.

as you could equally apply the twistyHidden class on the element in the template - I don't understand. What element, to do what?

AC


I have made some improvements to the javascript (SVN 7683). Still the best solution would be to let the plugin generate a list of twisty ids and write this list as javascript, and make the plugin enabled by default.

AC


A better solution, and one that can be applied to the Javascript for the Calendar popup and the calculator popup as well, is to have the skin only load the javascript the topic is going to make use of it. I asked for this a long tme ago.

-- AJA


That would also mean the plugin needs to be enabled, not the contrib. In fact the contrib should be merged (back) into the plugin. -- AC

I'm not desperately keen for this to be a plugin, because a plugin implies a lot of overhead that the contrib doesn't have (2-3 AthensMarks for each plugin). It would be better to make the JS more efficient. Anton, I hear you; and if the amount of JS being loaded was large, I'd be bothered.

What is the load time for TWikiVariables now, since your changes?

CC


Note that the plugin is just an "interface" to the Contrib. It only add the script line to the header and provide a set of convenience tags, but the whole responsability of managing the twisties is on the Contrib side.

I agree with Crawford in that the Contrib and the Plugin should remain separated. The Contrib can be used in any version of TWiki, and can be used (or not) by any skin without the need of the plugin.

RA


So (1) either pay the 2-3 AthensMarks for the plugin or (2) pay for the onload handler called for nothing. Hm, weird. I'd only opt for (1) if the twisty onload handler can't be optimized even further, like an itteration over an empty array. Right now it still does an active search on (a subset of) the html elements no matter what.

MD

Arthur explained what he is trying to do to me. Basically, he wants to hide all the twisty sections by default, but only if Javascript is enabled. So a user with JS disabled sees all the twisty contents. Anyone got any suggestions for a better way to do this (in JS)? AFAICT it either requires some sort of iteration over the elements, or some sort of iteration in the client that generates a list of IDs of affected elements.

The best I could come up with was the idea of a %UID{twisty}% twiki tag that generates a new unique sequential number each time it is called. So id="twisty$UID{twisty}" would be known to generate id="twisty0" the first time it is used, id="twisty1" the second and so on. You could then:

var n = 0;
var e;
while(e = getElementById("twisty"+(n++))) {
    ....
Of course, if there is a break in the sequence for any reason you're shafted, which is why I don't think this is very good.

CC

You can't garantee that every twisty is insterted using the plugin. If someone does one manually then you're stuffed.

I think we should allow manual inclusion of twisties as I think there are some ways that you can play about with the html to get different effects.

SH

Arthur seems to have made a lot of improvements. Closing. CC

ItemTemplate
Summary Optimize Twisty
ReportedBy ArthurClemens
Codebase

SVN Range Tue, 29 Nov 2005 build 7670
AppliesTo Extension
Component TwistyPlugin
Priority Normal
CurrentState Closed
WaitingFor

Checkins 7674 7675 7683 7763
Edit | Attach | Watch | Print version | History: r14 < r13 < r12 < r11 < r10 | Backlinks | Raw View |  Raw edit | More topic actions
Topic revision: r14 - 2005-12-04 - CrawfordCurrie
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback