On 11/12/09 1:56 PM, Denis Gervalle wrote:
On Nov 12, 2009, at 13:26, Vincent Massol wrote:
On Nov 12, 2009, at 12:56 PM, Jerome Velociter wrote:
Hello all,
I think it would be nice to have the possibility to post-load some of the JavaScript extensions, as a way to ease performance best practices for developers. (See http://developer.yahoo.com/performance/rules.html#postload for example).
It would also allow people to easily add hungry third party scripts (like the google analytics tracker) in a non intrusive manner and not sacrificing performance (no need to modify/override htmlfooter.vm for example, a simple SX always-use will do).
I see different ways of doing that :
1) Either we say all document JSX are post-loaded, and we move the hook down the DOM just before the closing</body> tag. 2) Either we have 2 hooks and we leave it as an option to be post- loaded.
My preference goes to 1), as I don't see any good use case where a extension would need not to be post-loaded; and 2) is not so elegant to implement with the current SX mecanism.
1) sounds good to me too but I'm not an expert (so I don't know if there are any drawbacks).
Even if I agree, I see at least potential issue for existing JSX, since code executed during page loading may be broken by a post-loaded extension. I think that we (at Softec) have at least one extension that would break, it is a implementation of the astable for backward compatibility.
Yes, we would need a backward compatibility path to get there. I'd say a flag in xwiki.cfg to keep the hook up in the header.
Another potential issue is our field validation extension that may be called by user interaction before the end of the page loading (browser dependent).
If I understand correctly, it's a design issue of the extension rather than a problem with post-loading. I'm guessing (stop me if I'm wrong) the extensions uses on(change|blur|keyup|etc.) hooks directly on the input fields - which I think is not a good practice. Instead I would use either CSS classes on the field + a initialization hook on DOM loading that finds all fields to bind to validation methods with a CSS selector, and/or directly Event#observe for more complex validations that cannot be expressed by just a class (cross fields validation, etc.).
So to avoid that, 2) is not a bad option either.
Denis
Thanks -Vincent
WDYT ?
(Note: I'm not talking about file-system extensions here (JSFX), though the question could be asked for them as well - I need to give it more thoughts)
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs