On 03/17/2010 01:37 PM, Anca Luca wrote: > Hi Jerome, > > On 03/17/2010 01:02 PM, Jerome Velociter wrote: >>> Hi Vincent, >>> >>> On 03/17/2010 11:44 AM, Vincent Massol wrote: >>>> >>>> On Mar 17, 2010, at 10:30 AM, Jerome Velociter wrote: >>>> >>>>>> Hi Jerome, >>>>>> >>>>>> On 03/15/2010 09:37 PM, Jerome Velociter wrote: >>>>>>>> Hi Vincent, all >>>>>>>> >>>>>>>> On 03/15/2010 12:15 PM, Vincent Massol wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> We've slipped badly for the 2.3M1 release (my fault for not >>>>>>>>> monitoring >>>>>>>>> it closely enough). It was planned on the 8th of March and we're >>>>>>>>> the >>>>>>>>> 15th already (one week delay). >>>>>>>>> >>>>>>>>> The other problem is that we don't have what we had imagined would >>>>>>>>> go >>>>>>>>> in >>>>>>>>> 2.3M1 (color theme improvement for ex). Right now there are lots of >>>>>>>>> changes but nothing really user-noticeable. >>>>>>>>> >>>>>>>>> So I'd suggest the following: >>>>>>>>> * Delay by a few days in order to be able to include: >>>>>>>>> - color theme improvement. Sergiu you need to tell us if that's >>>>>>>>> doable >>>>>>>>> and for when. >>>>>>>>> - captcha on comments. Caleb, let us know if that's all done or if >>>>>>>>> there's need for more testing/development. >>>>>>>>> >>>>>>>>> Bonus: >>>>>>>>> - Anca, will it be possible to have annotations released for 2.3M1 >>>>>>>>> (ie >>>>>>>>> now)? How much more time would you need? >>>>>>>> >>>>>>>> I'll close the vote for XWIKI-4775 asap, and commit it since it's >>>>>>>> due a >>>>>>>> long >>>>>>>> time now. >>>>>>>> I shouldn't need more than 2 days, but how would we want the >>>>>>>> annotations >>>>>>>> integrated in the platform? >>>>>>>> >>>>>>>> Right now they're built as an extension, with some jars to deploy on >>>>>>>> the >>>>>>>> server >>>>>>>> and a .xar to install the default annotations application. >>>>>>> >>>>>>> Annotations JS and CSS should be moved to web/standard/ as filesystem >>>>>>> extensions/resources (as are the other "core" UI features), not be >>>>>>> contained in the XAR. >>>>>> >>>>>> Actually that's a longer refactor, to actually make the Annotations >>>>>> part >>>>>> of the >>>>>> UI / skin, instead of having this integration done in js, after the >>>>>> pages >>>>>> get >>>>>> rendered. That's if we make it a core default feature. >>>>> >>>>> But isn't that what we are discussing right now, making it a core >>>>> feature? >>> >>> yes, but I don't think it's fully decided (should send a vote asap). >>> >>>>> >>>>> For me, as soon as we distribute annotations together with XE, their >>>>> should be not a single line of JavaScript in wiki documents. >>>>> (But that does not mean you need to rewrite everything so that more >>>>> comes >>>>> with the rendered DOM and less is injected/manipulated in JS - though I >>>>> agree it would be nicer if the annotations would work even when there >>>>> would be no JavaScript :) >>>> >>>> For me it should be packaged in the default XE but it should stay as >>>> separate as possible from the rest, i.e. it should be possible to have a >>>> working platform without the annotations feature. This is true for >>>> almost everything but for technical reason we cannot always do it. >>>> >>>> If we can keep it separate and use skin extensions for ex rather the >>>> having to modify existing templates, etc we should probably do that. >>> >>> We can keep it separate using the js and css that is currently in the >>> extensions, for the moment. >>> >>> But as a general strategy, if we "integrate" them in the default platform >>> / >>> enterprise and it gets stable enough, I don't see why they won't be >>> properly >>> integrated, i.e. instead of adding the "Annotations" tab shortcut from js, >>> put >>> it in the vms where the others are, same for the Annotations tab, etc. >>> >>> However, we need to make sure we preserve the level of customizability: >>> annotations are designed to be easily customizable, from forms and UI, to >>> js >>> powering functionality and all, easily *from the browser* with no >>> filesystem >>> access. I prefer it stays like that. >> >> The proper way of doing this is with an extension mechanism where wiki JSX >> (so in the browser) come and register new features/extensions against the >> generic annotation feature (a plugin system of some sort), not by letting >> developers modify the core of the annotation feature script (which makes >> it un-maintainable) > > Ideally yes, i've been thinking about this in the past days, and I still think > it's too much. > 1/ because it would mean maintaining an annotations js API, which sounds a bit > too much: we need to commit to it, make it backwards compatible, etc. However > if > it's part of the platform, then it follows all platform rules, among which js > API. "plugin system of some sort" it's a bit too much... > 2/ because chances are it won't be enough unless very granulated, and the > finer > the granulation, the bigger pain 1/ is > 3/ because customizations are not only at .js level, they would be at the > macros > & scripts generating the UI level too (documents now but templates in the > integration), for which building APIs is a bit harder (there is no way to > override a macro in velo iirc) and, again, "plugin system of some sort" > sounds a > bit too much and chances are it won't be enough.
Actually .js can be handled, to some extent, using events. And we can consider that we ignore 'the html issue' since it can all be modified from js provided that appropriate handlers can be registered. I don't like the second part that much though. Thanks, Anca > >> >>> >>> However, for the moment (2.3M1), that's quite a bit of refactoring (the >>> integration) which i'm not willing to do. >>> >>> So for M1 it would be either: >>> >>> 1/ all in xar (js, css, script documents with annotation forms) >> >> If it's only for M1 as a path to have the feature integrated in templates >> and resources, it means you are creating yourself a challenge for the >> migration path (you will need to find a way to delete or ignore the >> always-loaded SX from the wiki if at some point the make their ways into >> the core). > > That's a good point. Is it an option to have good release notes from M1 to M2 > and RCs and having it done nice for final? > > can the migration be handled with good release notes between milestones and > RCs? > (as in I agree this would be a mess for a final, but milestones have a > different > status...) > > Thanks, > Anca > >> >> >>> 2/ js& css in resources, script documents with annotation forms& other >>> scripted UI in .xar >> >> What does form and scripted UI means ? They are scripts that generated >> HTML loaded by AJAX in the pages ? (for example in the docExtra tabs ?) Or >> is it something else ? > > yes, that's what it means: the docExtra tab, all the annotation forms (create, > edit, display, etc) are html fetched with ajax from generating scripts in > xwiki > docs ftm, none is created from javascript, for customizability purposes. > >> >>> >>> My vote goes for 1/ since it's less mess. >> >> 0 >> >> Jerome. >> >>> >>> WDYT? >>> >>>> >>>> Thanks >>>> -Vincent >>>> >>>>> >>>>> Jerome. >>>>> >>>>> >>>>> >>>>>> >>>>>> Anca >>>>>> >>>>>>> >>>>>>> Jerome. >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Anca >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks >>>>>>>>> -Vincent >>>> _______________________________________________ >>>> 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
