BTW it would be interesting to review the wiki modules to verify they contain only base wiki APIs, because advanced wiki APIs could be considered extensions which are not required in the core and that extensions should depend on should they need them.
I don’t know the wiki modules well enough to judge at this point. Thanks -Vincent +1 The model is Wiki, Space, Document, (Class), Object. It does not make much (and seems like an arbitrary decision) to consider API for Space, Document, (Class), Object as core API, but API for wikis to be treated as non-core and optional. Yes, we come from a single-wiki initial implementation, but we have long evolved from that state and should, IMO, start behaving accordingly. For instance, when we write code, it should be a given the code itself runs on a multiwiki environment and it should run the same, whether it's on the main wiki or in a subwiki and it could even interact with documents from other wikis than the current one. Ideally the wiki API code should be located in oldcore, where the rest of the API for interacting with the model is located, but since we (decided that we) can not extend it any more (in an effort to deprecate it eventually), we ended up with a separate module which looks like it's separate, but actually belongs next to the other space, document, etc. API. Also note that the wiki API also comes with extra API about users and wiki type (wiki.user) and also with extra API when creating wikis from templtes (wiki.template). I`m not sure about these API and I guess we could let extensions explicitly depend on them if they need them to be present at runtime. Finally, if we are including java and script service API, I guess we need to include the REST API as well, which features only the creation methods. This as well should ideally be present in the base REST API, but since the whole wiki module was viewed as an extension before, this was the only way to add it. If we change our point of view now, perhaps it could be merged with the base REST API, since that is outside oldcore. Even the now old "new model", that we are trying for years now to do, includes wikis as first class citizens. Thanks, Eduard On Mon, Aug 31, 2015 at 6:33 PM, [email protected] <[email protected]> wrote: > > +1 (forgot to vote), even though I don’t like that we make the core larger > than it could be. See IRC discussion at > http://dev.xwiki.org/xwiki/bin/view/IRC/xwikiArchive20150831 > > Thanks > -Vincent > > > On 31 Aug 2015 at 16:17:59, [email protected] ([email protected](mailto: > [email protected])) wrote: > > > Hi devs, > > > > Problem: > > > > * We have several ways of getting the main wiki id and the current wiki > id: > > ** way 1: $services.wiki.mainWikiId and $services.wiki.currentWikiId > > ** way 2: $xcontext.getMainWikiName() and $context.getDatabase() > > * In menu_macros.vm we set: #set ($mainWikiId = > $services.wiki.mainWikiId) > > ** This is used in some other templates such as drawer.vm: > > #set ($hasHomeWikiAdmin = $xwiki.hasAccessLevel('admin', $xcontext.user, > "${mainWikiId}:XWiki.XWikiPreferences”)) > > ** This means that currently is a module doesn’t declare a dependency on > the wiki module, its functional tests will fail with: > > > > 15:29:29.868 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 > 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] > WARN o.h.u.JDBCExceptionReporter - SQL Error: -4850, SQLState: 3F000 > > 15:29:29.869 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 > 15:29:29,868 [http://localhost:8080/xwiki/bin/register/XWiki/Register] > ERROR o.h.u.JDBCExceptionReporter - invalid schema name: ${MAINWIKIID} > > 15:29:29.884 [Thread-13] ERROR o.x.t.i.XWikiLogOutputStream - 2015-08-31 > 15:29:29,883 [http://localhost:8080/xwiki/bin/register/XWiki/Register] > ERROR .a.DefaultAuthorizationManager - Failed to load rights for user > [Public] on [${mainWikiId}:XWiki.XWikiPreferences]. > > > > Solution: > > > > * Make the Wiki API Module and the Wiki Script Module a core API (ie the > most minimal version of XWiki cannot work without them) > > > > Actions to take: > > > > * Add a dep on these 2 modules in PackagerMojo.java > > * Deprecate $xcontext.getMainWikiName() and $context.getDatabase() and > favor using $services.wiki.mainWikiId and $services.wiki.currentWikiId > (once we finish adjusting all places, move xcontext.getMainWikiName() and > context.getDatabase to the oldcore legacy module). > > * Remove all the checks we do to check for the availability of the wiki > script service. For example: > > > > admin.vm: #if ("$!services.wiki" != '' && $services.wiki.currentWikiId > != $services.wiki.mainWikiId) > > Activity.xml: #if ("$!services.wiki" != '' && $services.wiki.mainWikiId > == $services.wiki.currentWikiId) > > menuview.vm: #set ($isWikiAPIAvailable = ("!$services.wiki" != '') && > ("!$services.wiki.user" != '')) > > CreateWiki.xml: #if ($services.wiki && $services.wiki.creationjob) > > > > > > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
