On Nov 12, 2009, at 14:44, Jerome Velociter wrote:
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.
This would prevent smooth evolution, in particular for a XWiki farm, since all extension had to be fixed up before a transition occurs.
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.
This is completely right.
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.).
This is not the sole issue. For astable, the practice was direct call in the document to put hooks on the astable, so it had to be available before the body starts. This is not good design, but it was the way it had works, and our extension just ensure backward compatibility. So, this why I suggest 2) to be as flexible as possible.
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs