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