On 10/31/2012 10:00 PM, Fabio Mancinelli wrote:
Resurrecting the thread because there is an issue :)
On Wed, Oct 10, 2012 at 7:44 PM, Fabio Mancinelli
<[email protected]> wrote:
On Wed, Oct 10, 2012 at 4:48 PM, Vincent Massol <[email protected]> wrote:
On Oct 10, 2012, at 4:39 PM, Fabio Mancinelli <[email protected]>
wrote:
Hi everybody,
I will try to go forward in committing REST API improvements made by
Ludovic and me.
Looking at the discussion about the pull request I opened
https://github.com/xwiki/xwiki-platform/pull/68
Thomas pointed out the fact that it brings
"xwiki-platform-wiki-manager-api" as a dependency in XE, and this
might require a vote.
xwiki-platform-wiki-manager-api is something that was bundled only in
XEM and not in XE.
I added it as a dependency because I use its code for performing wiki
creation and XAR importing.
Thomas' comment is here:
https://github.com/xwiki/xwiki-platform/pull/68#discussion_r1335333
So the vote is about the bundling of xwiki-platform-wiki-manager-api
in XE for merging this pull request.
I am +1, of course.
-1 ATM until convinced otherwise. This would be a mess. Our goal is to do the
opposite and remove dependencies not create new ones :)
Thanks. Actually I agree with your -1.
Each module should bring its own REST resources so the wiki creation REST
resource should go in wiki-manager-api or in a new wiki-manager-rest module.
Ok, so the idea is to add a new module that is bundled only with XEM
and that add wiki creation if present. Which sounds good.
I need to check if it's feasible though...
The problem here is the following: The core REST API which is based on
the very XWiki model, "talks" about wikis.
Now the resource about wikis "/rest/wikis/{wiki}" is in the core REST
API that is bundled in the REST module in XE.
So wiki creation should refer to this resource: in the current
implementation, in fact, it is a POST method of the resource
associated to "/rest/wikis".
Now if we want to move this functionality in XEM we should be able to
bundle a resource that points to "/rest/wikis" as well and add the
POST handling.
In principle should be ok, but I have to be check it. Because in this
case we will have two classes that are annotated with the same @Path
annotation and I don't know if Restlet JAXRS is going to like it.
I checked this and it doesn't work :(
The REST API registers a /wikis resource that accepts a GET.
In a new wiki manager module we would need to "augment" this resource
so that it can handle POSTs (i.e., a POST to /rest/wikis to create a
wiki)
The problem is that we cannot register two resources that have the
same @Path annotation (i.e. /rest/wikis), even though there is no
ambiguity in how they handle the requests (i.e., GET in one resource,
and POST in the other)
Is this a limitation of Restlet ?
Jerome
An (quite ugly) workaround, since we cannot bundle wiki manager with
XE, is to bind wiki manager REST API to other endpoints:
* POST /rest/wiki-manager/wikis for creating wikis
* GET /rest/wiki-manager/wikis for getting a list of wikis (redundant,
similar to /rest/wikis/)
* DELETE /rest/wiki-manager/wikis/{wikiName} to delete a wiki
It's a pity because we could have modeled these operations with the
resources we currently have, but it's technically infeasible.
WDYT?
-Fabio
P.S.: I've reas that the RESTEasy is able to do that. But Restlet (and
also Jersey) aren't.
Same for XAR importing. There should one XAR importing REST API that works
without wiki-manager-api (just using oldcore's Packager) and possibily another
one in wiki-manager-api which may extend the simpler one (or create a new one
altogether) for importing in several wikis.
Actually I was wrong in the description of the functionality. The
dependency on wiki manager is needed only for wiki creation. XAR
importing is done using the packager plugin in the oldcore, so it
would work normally even if wiki manager is not there.
Thanks,
Fabio
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
