12 Nov
2009
12 Nov
'09
12:56 p.m.
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.
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.
12 Nov
12 Nov
1:25 p.m.
Hi Jerome,
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.
This poses a problem in WYSIWYG editing mode. I'm currently loading the
JSX in edit mode in order for the page to look as in view mode. Placing
the hook inside the editable body is dangerous.
Marius
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.
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
2:50 p.m.
On 11/12/09 1:25 PM, Marius Dumitru Florea wrote:
Hi Jerome,
Jerome Velociter wrote:
In the case of the WYSIWYG we could keep it in the header (I believe you
already are placing the hook yourself and do not use javascript.vm,
right ?).
BTW is it such a good idea to load extensions in edit mode?
I'm not very convinced, since some extensions could affect the content
of the edited DOM, leading to weird content. (Think about the addSizes
extension of the SX tutorial for example
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
Jerome.
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.
This poses a problem in WYSIWYG editing mode. I'm currently loading the
JSX in edit mode in order for the page to look as in view mode. Placing
the hook inside the editable body is dangerous.
Marius
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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:54 p.m.
Jerome Velociter wrote:
On 11/12/09 1:25 PM, Marius Dumitru Florea wrote:
I'm including the javascript.vm and thus I inherit the hook position (as
long as the position is in the head of course).
Now, wouldn't be better to write a JSX post-onload downloader? It should
be small enough to be placed in the head and it will fetch all the
deferrable JSX after the DOM is ready. I understand that some JS
frameworks already support this. WDYT?
Hi Jerome,
Jerome Velociter wrote:
In the case of the WYSIWYG we could keep it in the header (I believe you
already are placing the hook yourself and do not use javascript.vm,
right ?). 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.
This poses a problem in
WYSIWYG editing mode. I'm currently loading the
JSX in edit mode in order for the page to look as in view mode. Placing
the hook inside the editable body is dangerous.
BTW is it such a good idea to load extensions in edit mode?
I'm not very convinced, since some extensions could affect the content
of the edited DOM, leading to weird content. (Think about the addSizes
extension of the SX tutorial for example
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
There were some complains regarding the fact that the live table doesn't
look the same in edit mode so I had to load the extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
Jerome.
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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.
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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
13 Nov
13 Nov
8:05 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
[snip]
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
tend to think it would have been enough to have the proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I don't like too much the strategy that would say "extensions developers
have to check if they are executed in the WYSIWYG (I guess it's
possible, not tried yet) and adapt the extension behavior accordingly"
Feels somehow a bit too complex.
Jerome.
BTW is it such a good idea to load extensions in edit mode?
I'm not very convinced, since some extensions could affect the content
of the edited DOM, leading to weird content. (Think about the addSizes
extension of the SX tutorial for example
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
There were some complains regarding the fact that the live table doesn't
look the same in edit mode so I had to load the extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
8:16 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter <jerome(a)xwiki.com> wrote:
On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
[snip]
I'm pretty sure we discussed it since I recall discussing about this with
Vincent about this in the past (maybe 1 year ago, when we started working on
the new editor.) Marius eventually implemented full rendering and we went
along with it up to today.
It has some great advantages (live macro rendering looks cool in demos) but
also some drawbacks. Additionally, I'm afraid that the cost of making live
rendering in edition mode work flawlessly will take a *lot* of work given
the huge complexity and variety of situations that might be encoutered.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
>
> BTW is it such a good idea to load extensions in edit mode?
> I'm not very convinced, since some extensions could affect the content
> of the edited DOM, leading to weird content. (Think about the addSizes
> extension of the SX tutorial for example
>
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
There were some complains regarding the fact that the live table doesn't
look the same in edit mode so I had to load the extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
tend to think it would have been enough to have the
proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I agree with Jérôme here. I think we might have been aiming too high. While
it's very cool to have simple macros such as the ToC one execute right away
in the browser, maybe we could add a default "executeInEditMode" parameter
to all macros that lets the macro authors and/or users state whether they
want their macros to get executed in the WYSIWYG or to use a placeholder
instead.
In many cases, trying to display what's in the macro / embedded code leads
to issues of usability, performance and sometimes plain bugs as illustrated
by the livetable example. We're already going back in some cases such as the
Flash one.
WDYT?
I don't like too much the strategy that would say "extensions developers
have to check if they are executed in the WYSIWYG (I
guess it's
possible, not tried yet) and adapt the extension behavior accordingly"
Feels somehow a bit too complex.
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
8:31 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<jerome(a)xwiki.com> wrote:
Well rendering macros and executing javascript code are different
things. I think still in favor of executing macros (though maybe the
parameter makes sense, I haven't though about it too much).
Executing JS is different, it potentially can affect the whole document
content, and there is no way we will be able to deal with it 100%, even
introducing the transformation markers (how do we manage the extensions
that remove content, can we mark that ? how do we manage external
libraries like the lightbox one that are not aware of the WYWISYG and
its markers ? etc.)
Jerome.
On 11/12/09 3:54 PM, Marius Dumitru Florea
wrote:
[snip]
I'm pretty sure we discussed it since I recall discussing about this with
Vincent about this in the past (maybe 1 year ago, when we started working on
the new editor.) Marius eventually implemented full rendering and we went
along with it up to today.
It has some great advantages (live macro rendering looks cool in demos) but
also some drawbacks. Additionally, I'm afraid that the cost of making live
rendering in edition mode work flawlessly will take a *lot* of work given
the huge complexity and variety of situations that might be encoutered.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
>
> BTW is it such a good idea to load extensions in edit mode?
> I'm not very convinced, since some extensions could affect the content
> of the edited DOM, leading to weird content. (Think about the addSizes
> extension of the SX tutorial for example
>
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
There were some complains regarding the fact that the live table doesn't
look the same in edit mode so I had to load the extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
tend to think it would have been enough to have
the proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I agree with Jérôme here. I think we might have been aiming too high. While
it's very cool to have simple macros such as the ToC one execute right away
in the browser, maybe we could add a default "executeInEditMode" parameter
to all macros that lets the macro authors and/or users state whether they
want their macros to get executed in the WYSIWYG or to use a placeholder
instead.
In many cases, trying to display what's in the macro / embedded code leads
to issues of usability, performance and sometimes plain bugs as illustrated
by the livetable example. We're already going back in some cases such as the
Flash one.
WDYT?
I don't like too much the strategy that would say "extensions developers
have to check if they are executed in the WYSIWYG
(I guess it's
possible, not tried yet) and adapt the extension behavior accordingly"
Feels somehow a bit too complex.
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:44 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
Hi,
On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter <jerome(a)xwiki.com> wrote:
--
Guillaume Lerouge
Product Manager - XWiki SAS
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
I'm pretty sure we discussed it since I recall discussing about this with
Vincent about this in the past (maybe 1 year ago, when we started working on
Actually maybe this is a non-issue / best practice to publish for macro
writers since it's very easy to write something like:
{{velocity}}
#if($context.action == 'edit')
Placeholder
#else
JavaScript Code
#end
{{/velocity}}
WDYT?
Guillaume
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<jerome(a)xwiki.com>
wrote:
> On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
>
> [snip]
>>>
>>> BTW is it such a good idea to load extensions in edit mode?
>>> I'm not very convinced, since some extensions could affect the content
>>> of the edited DOM, leading to weird content. (Think about the addSizes
>>> extension of the SX tutorial for example
>>>
>
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
>>
>> There were some complains regarding the fact that the live table
doesn't
look the same in edit mode so I had to load the
extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
the new editor.) Marius eventually implemented
full rendering and we
went
along with it up to today.
It has some great advantages (live macro rendering looks cool in demos)
but
also some drawbacks. Additionally, I'm afraid
that the cost of making
live
rendering in edition mode work flawlessly will
take a *lot* of work given
the huge complexity and variety of situations that might be encoutered.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
While
tend to think it would have been enough to have
the proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I agree with Jérôme here. I think we might have been aiming too high. it's very cool to have simple macros such as
the ToC one execute right
away
in the browser, maybe we could add a default
"executeInEditMode"
parameter
to all macros that lets the macro authors and/or
users state whether they
want their macros to get executed in the WYSIWYG or to use a placeholder
instead.
Well rendering macros and executing javascript code are different
things. I think still in favor of executing macros (though maybe the
parameter makes sense, I haven't though about it too much).
Executing JS is different, it potentially can affect the whole document
content, and there is no way we will be able to deal with it 100%, even
introducing the transformation markers (how do we manage the extensions
that remove content, can we mark that ? how do we manage external
libraries like the lightbox one that are not aware of the WYWISYG and
its markers ? etc.)
Jerome.
In many cases, trying to display what's in the macro / embedded code
leads
to issues of usability, performance and sometimes
plain bugs as
illustrated
by the livetable example. We're already going
back in some cases such as
the
Flash one.
WDYT?
I don't like too much the strategy that would say "extensions developers
> have to check if they are executed in the WYSIWYG (I guess it's
> possible, not tried yet) and adapt the extension behavior accordingly"
> Feels somehow a bit too complex.
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
9:56 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
On 11/13/09 8:44 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter<jerome(a)xwiki.com> wrote:
That's both not the problem, and a wrong solution :)
That's not the problem, because the javascript code is not inline (it's
in a script tag that get injected in the <head> by the SX plugins), and
can be there because it's an "Always used" extension (so no
$xwiki.jsx.use call that you could skip in edit mode).
And that would have not been a solution because the WYSIWYG renders
actually the content in view mode, not edit.
When I mentioned the strategy of developers testing if they are getting
executed in the WYSIWYG, it was from the pure JavaScript side, not from
the wiki content / velocity one. So something like checking for the
presence of some functions/variables that exists only in the context of
the WYSIWYG, or looking at structure of the frame to know if current
frame is the top level window or not, etc - haven't looked into it really).
Hope it clarifies,
Jerome.
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
on
Actually maybe this is a non-issue / best practice to publish for macro
writers since it's very easy to write something like:
{{velocity}}
#if($context.action == 'edit')
Placeholder
#else
JavaScript Code
#end
{{/velocity}}
WDYT? Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<jerome(a)xwiki.com>
wrote:
> On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
>
> [snip]
>>>
>>> BTW is it such a good idea to load extensions in edit mode?
>>> I'm not very convinced, since some extensions could affect the content
>>> of the edited DOM, leading to weird content. (Think about the addSizes
>>> extension of the SX tutorial for example
>>>
>
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
>>
>> There were some complains regarding the fact that the live table
doesn't
> look
the same in edit mode so I had to load the extensions in edit mode
> ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
> example. Once we have transformation markers any JSX will be able to
> change the DOM provided the changes are marked. Also, I'm thinking that
> a macro could use a JSX to "draw" something on the page. If JSX are not
> loaded in edit mode the page will look different.
>
> Marius
>
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
I'm pretty sure we discussed it since I recall discussing about this with
Vincent about this in the past (maybe 1 year ago, when we started working the new editor.) Marius eventually implemented
full rendering and we
went
along with it up to today.
It has some great advantages (live macro rendering looks cool in demos)
but
also some drawbacks. Additionally, I'm afraid
that the cost of making
live
rendering in edition mode work flawlessly will
take a *lot* of work given
the huge complexity and variety of situations that might be encoutered.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
While
tend to think it would have been enough to have
the proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I agree with Jérôme here. I think we might have been aiming too high. it's very cool to have simple macros such as
the ToC one execute right
away
in the browser, maybe we could add a default
"executeInEditMode"
parameter
to all macros that lets the macro authors and/or
users state whether they
want their macros to get executed in the WYSIWYG or to use a placeholder
instead.
Well rendering macros and executing javascript code are different
things. I think still in favor of executing macros (though maybe the
parameter makes sense, I haven't though about it too much).
Executing JS is different, it potentially can affect the whole document
content, and there is no way we will be able to deal with it 100%, even
introducing the transformation markers (how do we manage the extensions
that remove content, can we mark that ? how do we manage external
libraries like the lightbox one that are not aware of the WYWISYG and
its markers ? etc.)
Jerome.
In many cases, trying to display what's in the macro / embedded code
leads
to issues of usability, performance and sometimes
plain bugs as
illustrated
by the livetable example. We're already going
back in some cases such as
the
Flash one.
WDYT?
I don't like too much the strategy that would say "extensions developers
> have to check if they are executed in the WYSIWYG (I guess it's
> possible, not tried yet) and adapt the extension behavior accordingly"
> Feels somehow a bit too complex.
Guillaume
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:26 p.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
On 11/13/09 9:56 PM, Jerome Velociter wrote:
On 11/13/09 8:44 PM, Guillaume Lerouge wrote:
OK, the solution would have worked in fact, so that leave it just "not
the problem" :)
Jerome.
Hi,
On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter<jerome(a)xwiki.com> wrote:
That's both not the problem, and a wrong solution :)
That's not the problem, because the javascript code is not inline (it's
in a script tag that get injected in the<head> by the SX plugins), and
can be there because it's an "Always used" extension (so no
$xwiki.jsx.use call that you could skip in edit mode).
And that would have not been a solution because the WYSIWYG renders
actually the content in view mode, not edit.
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Actually maybe this is a non-issue / best practice
to publish for macro
writers since it's very easy to write something like:
{{velocity}}
#if($context.action == 'edit')
Placeholder
#else
JavaScript Code
#end
{{/velocity}}
WDYT?
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<jerome(a)xwiki.com>
wrote:
> On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
>
> [snip]
>
>>> BTW is it such a good idea to load extensions in edit mode?
>>> I'm not very convinced, since some extensions could affect the content
>>> of the edited DOM, leading to weird content. (Think about the addSizes
>>> extension of the SX tutorial for example
>>>
>>>
>
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
>> There were some complains regarding the
fact that the live table
>>
doesn't
>> look the same in edit mode so I had to
load the extensions in edit mode
>> ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
>> example. Once we have transformation markers any JSX will be able to
>> change the DOM provided the changes are marked. Also, I'm thinking that
>> a macro could use a JSX to "draw" something on the page. If JSX are
not
>> loaded in edit mode the page will look different.
>>
>> Marius
>>
>>
> http://markmail.org/thread/rubnuunk4vd25bzt see :)
>
> I don't remember we've voted on that, we probably should have. I'm
> really not fan of executing the scripts in the WYSIWYG, in the end.
> Even the "mark DOM changes" technique will not be enough, as we can't
> control how JS libraries we use do inject their content (typically the
> lightbox code here) and most extensions are made of/rely on external
> libraries.
>
>
I'm pretty sure we discussed it since I recall discussing about this with
Vincent about this in the past (maybe 1 year ago, when we started working
on
the new editor.) Marius eventually implemented
full rendering and we
went
along with it up to today.
It has some great advantages (live macro rendering looks cool in demos)
but
also some drawbacks. Additionally, I'm afraid
that the cost of making
live
rendering in edition mode work flawlessly will
take a *lot* of work given
the huge complexity and variety of situations that might be encoutered.
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
> tend to think it would have been enough to have the proper CSS, but not
> the JS (and have the table would remain empty). I don't see the value of
> having the tables really work in edit mode. (Except for saying "it's
> really WYSIWYG").
>
>
I agree with Jérôme here. I think we might have been aiming too high.
While
it's very cool to have simple macros such as
the ToC one execute right
away
in the browser, maybe we could add a default
"executeInEditMode"
parameter
to all macros that lets the macro authors and/or
users state whether they
want their macros to get executed in the WYSIWYG or to use a placeholder
instead.
Well rendering macros and executing javascript code are different
things. I think still in favor of executing macros (though maybe the
parameter makes sense, I haven't though about it too much).
Executing JS is different, it potentially can affect the whole document
content, and there is no way we will be able to deal with it 100%, even
introducing the transformation markers (how do we manage the extensions
that remove content, can we mark that ? how do we manage external
libraries like the lightbox one that are not aware of the WYWISYG and
its markers ? etc.)
Jerome.
In many cases, trying to display what's in
the macro / embedded code
leads
to issues of usability, performance and sometimes
plain bugs as
illustrated
by the livetable example. We're already going
back in some cases such as
the
Flash one.
WDYT?
I don't like too much the strategy that would say "extensions developers
> have to check if they are executed in the WYSIWYG (I guess it's
> possible, not tried yet) and adapt the extension behavior accordingly"
> Feels somehow a bit too complex.
>
When I mentioned the strategy of developers testing if
they are getting
executed in the WYSIWYG, it was from the pure JavaScript side, not from
the wiki content / velocity one. So something like checking for the
presence of some functions/variables that exists only in the context of
the WYSIWYG, or looking at structure of the frame to know if current
frame is the top level window or not, etc - haven't looked into it really).
Hope it clarifies,
Jerome.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
Jerome.
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
14 Nov
14 Nov
10:43 a.m.
New subject: [xwiki-devs] On JS execution in the WYSIWYG (was Re: [Idea] Post-loaded JSX)
Hi Jerome,
Jerome Velociter wrote:
On 11/12/09 3:54 PM, Marius Dumitru Florea wrote:
[snip]
http://markmail.org/thread/rubnuunk4vd25bzt see :)
I don't remember we've voted on that, we probably should have. I'm
really not fan of executing the scripts in the WYSIWYG, in the end.
Even the "mark DOM changes" technique will not be enough, as we can't
control how JS libraries we use do inject their content (typically the
lightbox code here) and most extensions are made of/rely on external
libraries.
In the same way, blocking JSX doesn't prevent a user from writing a
dangerous script tag inside the HTML macro or a wiki macro author to
generate a script tag that alters the DOM outside the macro markers. I
can't really prevent JavaScript execution in WYSIWYG edit mode unless
the renderer strips all script tags. Do we want this? I'm not against.
BTW is it
such a good idea to load extensions in edit mode?
I'm not very convinced, since some extensions could affect the content
of the edited DOM, leading to weird content. (Think about the addSizes
extension of the SX tutorial for example
http://platform.xwiki.org/xwiki/bin/view/DevGuide/SkinExtensionsTutorial).
There
were some complains regarding the fact that the live table doesn't
look the same in edit mode so I had to load the extensions in edit mode
( http://jira.xwiki.org/jira/browse/XWIKI-3991 ). This is just an
example. Once we have transformation markers any JSX will be able to
change the DOM provided the changes are marked. Also, I'm thinking that
a macro could use a JSX to "draw" something on the page. If JSX are not
loaded in edit mode the page will look different.
Marius
For the livetables ( http://jira.xwiki.org/jira/browse/XWIKI-3991 ) I
tend to think it would have been enough to have the proper CSS, but not
the JS (and have the table would remain empty). I don't see the value of
having the tables really work in edit mode. (Except for saying "it's
really WYSIWYG").
I don't like too much the strategy that would say
"extensions developers
have to check if they are executed in the WYSIWYG (I guess it's
possible, not tried yet) and adapt the extension behavior accordingly"
Feels somehow a bit too complex.
I think it's also the responsibility of the extension author to make
sure its extension behaves well in WYSIWYG edit mode. If there is a way
to write an extension so that it looks nice in edit mode, some
developers might appreciate it.
So is it really useful to execute the JavaScript in edit mode?
Thanks,
Marius
Jerome.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Nov
12 Nov
1:26 p.m.
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).
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.
1:56 p.m.
On Nov 12, 2009, at 13:26, Vincent Massol wrote:
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. Another potential issue is our field validation
extension that may be called by user interaction before the end of the
page loading (browser dependent).
So to avoid that, 2) is not a bad option either.
Denis
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).
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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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
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
13 Nov
13 Nov
3:33 a.m.
On 11/12/2009 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.
Wouldn't the defer attribute be much simpler? It does almost the same
thing, but using only HTML, and requires very little changes.
We can add a new property in the JSX class to differentiate defered and
non-defered extensions.
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.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5423
days inactive
5425
days old
15 comments
6 participants
participants (6)
-
Denis Gervalle -
Guillaume Lerouge -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol