[xwiki-devs] [Idea] Post-loaded JSX
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 11/12/09 1:25 PM, Marius Dumitru Florea wrote:
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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Jerome Velociter wrote:
On 11/12/09 1:25 PM, Marius Dumitru Florea wrote:
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.
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 ?).
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?
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
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 [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
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. 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.
Hi, On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter <[email protected]> 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. 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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<[email protected]> 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.
I agree. The "don't execute in WYSIWYG editor" parameter for macros could be a solution here.
Guillaume
Jerome.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter <[email protected]> wrote:
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<[email protected]> 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.
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
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
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
-- Guillaume Lerouge Product Manager - XWiki SAS Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
On 11/13/09 8:44 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter<[email protected]> wrote:
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<[email protected]> 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.
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?
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.
Guillaume
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
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
On 11/13/09 9:56 PM, Jerome Velociter wrote:
On 11/13/09 8:44 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:31 PM, Jerome Velociter<[email protected]> wrote:
On 11/13/09 8:16 PM, Guillaume Lerouge wrote:
Hi,
On Fri, Nov 13, 2009 at 8:05 PM, Jerome Velociter<[email protected]>
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.
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?
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.
OK, the solution would have worked in fact, so that leave it just "not the problem" :) Jerome.
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
I agree. The "don't execute in WYSIWYG editor" parameter for macros could
be
a solution here.
Guillaume
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
Hi Jerome, Jerome Velociter 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.
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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.
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. 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
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
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
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
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/
participants (6)
-
Denis Gervalle -
Guillaume Lerouge -
Jerome Velociter -
Marius Dumitru Florea -
Sergiu Dumitriu -
Vincent Massol