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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
