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