+1 to remove it since we did not really use it in the end. <thread-highjacking>
Side note: Re XClasses in UI modules, I am beginning more and more to think that we need to use a new convention that is additional to -ui and -api packages which should be targeted at an extension's model when it involves XClasses. Mentioning this because XClasses are not really UI and are needed really by the -api modules more than the -ui modules. Also, there are a lot of cases when an extension X depends on extension Y-api, but that extension also has XClasses defined in its Y-ui module which would force extension X to actually depend on Y-ui which is not right IMO. Perhaps this deserves a thread of its own. Side note2: Re mandatory classes defined in Java, I am really more in favor of XClasses defined in XMLs instead of java (since most of the time the java classes are non-conditional, i.e. the properties we add do not depend on certain conditions so they can easily be replaced by a static XML), all we need is to add a new meta-property to a class that defines it as mandatory. Again, perhaps a separate thread. </thread-highjacking> Thanks, Eduard On Fri, Mar 20, 2015 at 12:57 PM, [email protected] <[email protected]> wrote: > Hi devs, > > In xwiki-enteprise we have XWiki.RequiredRightClass. We’ve started > discussing it in the past in the “Split XE pages” mail thread and I’d like > to move forward. > > So we need to decide what to do about it. Several options: > > * We discussed moving it to xwiki-platform-administration but it shouldn’t > go there IMO since we’re trying to make this module almost empty (just > providing the extension points mechanism) and have admin features > dispatched in the modules providing them. Also it would mean forcing > unnecessary dependencies on xwiki-platform-administration from several > modules (6-7 right now). > * It could go in a new xwiki-platform-security-ui module. > * It could be moved to Java but we don’t have a clear policy nor decision > if we want to favor xclasses written in java or opposite, decide that we > don’t want that and move away from XClasses in Java. So we’d need to decide > this first. > * We could also simply remove it! Rationale: > ** I don’t think we’re using that information much and its need is > supposed to go away once signed scripts is there > ** There’s no way to force pages requiring PR to add such an XObject and > thus it’s not done consistently > ** We don’t even have a page listing all pages requiring PR and even if we > had one I’m not exactly what it would bring. I guess the idea was to make > it simpler to install/upgrade XWiki but we’ve fixed this already in the > Wiki Creation Wizard for example so the need is less now. > > So overall I’m more in favor of dropping this experiment which IMO wasn’t > very successful. > > WDYT? > > 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
