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