[snip] >> 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.
Yes, that's what I had in mind. > 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. What is the 'HTML issue' ? I don't understand what you mean by that. Jerome. > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
