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, vincent(a)massol.net <vincent(a)massol.net>
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, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs