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