On 03/17/2010 11:34 AM, Anca Luca 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. > > 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) > 2/ js& css in resources, script documents with annotation forms& other > scripted UI in .xar > > My vote goes for 1/ since it's less mess.
+1 for 1/ -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
