12 Nov
2009
12 Nov
'09
2:44 p.m.
On 11/12/09 1:56 PM, Denis Gervalle wrote:
On Nov 12, 2009, at 13:26, Vincent Massol wrote:
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.
On Nov 12, 2009, at 12:56 PM, Jerome Velociter
wrote:
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. 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).
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs