12 Nov
2009
12 Nov
'09
4:58 p.m.
On Nov 12, 2009, at 14:44, Jerome Velociter wrote:
This is completely right.
On 11/12/09 1:56 PM, Denis Gervalle wrote:
This would prevent smooth evolution, in particular for a XWiki farm,
since all extension had to be fixed up before a transition occurs.
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.).
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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