[xwiki-devs] Any other comments to XWIKI-2428 (renamePage method)?
Dear all, I would like to add this improvement http://jira.xwiki.org/jira/browse/XWIKI-2428 I replied to Vincent's comment but there are no follow-ups. WDYT? Cheers, Fabio
On Jun 9, 2008, at 11:56 AM, Fabio Mancinelli wrote:
Dear all,
I would like to add this improvement http://jira.xwiki.org/jira/browse/XWIKI-2428 I replied to Vincent's comment but there are no follow-ups.
I thought about it after you commented but I was not able to find a good solution in the time I spent. I started to reply but I scraped my answer when I realized I just hasn't given it enough thoughts... Ideally I would have preferred that we implement the confluence API in one flavor of our XMLRPC API so that it's 100% compatible and that in the other flavor we implement the XWiki API (with objects, classes, different rename, etc). This is so that we can say we implement the Confluence API and so that existing tool that work with a confluence back end will work with XWiki. To be honest we haven't used any confluence tool so far but maybe we should list them and check if some are useful for us. For example: http://confluence.atlassian.com/display/CONFEXT/Tools Or maybe this is just too much work and we should not try to implement fully the Confluence XMLRPC interface? One use case that I think is interesting to keep would be to be able to use XEclipse to convert from confluence to xwiki: * in XEclipse you connect to both a confluence server and to a xwiki server * in the confluence connection you navigate to a page * you right click and select "convert to xwiki..." * You select the destination in the connected xwiki server Thanks -Vincent
On 9 juin 08, at 12:12, Vincent Massol wrote:
Ideally I would have preferred that we implement the confluence API in one flavor of our XMLRPC API so that it's 100% compatible and that in the other flavor we implement the XWiki API (with objects, classes, different rename, etc). This is so that we can say we implement the Confluence API and so that existing tool that work with a confluence back end will work with XWiki.
Thanks for your reply... Actually, after having read your mail and reflected a little more on the question maybe I have a solution. As I said in the Jira comment the problem is that we cannot be 100% compatible because we are semantically incompatible with the way Confluence handles pages. The way confluence clients rename pages is the following: page = getPage(pageId); page.setSpace("New space"); page.setTitle("New title"); storePage(page); In XWiki in order to rename a page we need to change its ID, and no client written for confluence will do this. Currently the authoritative source for the page location is the ID (basically storePage ignores the space field) and changing the title will only affect the page title. However if we agree to assume that the when using XMLRPC the semantics of the page title is that of the page name in an XWiki ID, we will be able to be confluence compatible. I see the following cases: Let P=(id, space, title) the definition of a page. Let CP be the current page and NP the page to be stored (i.e. the page passed to storePage): 1) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "NewSpace", "Title") Here it is clear that the user wants to "rename" the page by moving it to another space. So we rename the page to ("NewSpace.Name", "NewSpace", "Title") 2) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "NewSpace", "NewTitle"); Here it is also clear that we want to move the page to NewSpace but we have a problem about how to name the new page: NewSpace.Name or NewSpace.NewTitle? According to the assumption stated before, we rename the page and use NewTitle as the page name. The renamed page will have the NewSpace.NewTitle id. We also set the renamed page title to NewTitle. 3) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "Space", "NewTitle"); Here we have an ambiguity. Does the user want to to rename the page or set its title? According to the assumption stated before we assume that the user wants to rename the page so we will rename the page to Space.NewTitle and set its title to NewTitle. This solves the compatibility problem, but we have drawback: we need an extra method for simply changing the title without having the side effect of renaming the page. However this is not a big deal because it will be XWiki specfic and XEclipse might use that call when it detects it is talking to an XWiki and the user simply wants to change the title. In Confluence such an operation would not make sense, so XEclipse will not even present the "change title" option when talking to a confluence server. I think this solves the issue. If this sound good to you I might start to modify the storePage method for implementing the new semantics. WDYT? Cheers, Fabio
On Jun 9, 2008, at 2:16 PM, Fabio Mancinelli wrote:
On 9 juin 08, at 12:12, Vincent Massol wrote:
Ideally I would have preferred that we implement the confluence API in one flavor of our XMLRPC API so that it's 100% compatible and that in the other flavor we implement the XWiki API (with objects, classes, different rename, etc). This is so that we can say we implement the Confluence API and so that existing tool that work with a confluence back end will work with XWiki.
Thanks for your reply...
Actually, after having read your mail and reflected a little more on the question maybe I have a solution.
As I said in the Jira comment the problem is that we cannot be 100% compatible because we are semantically incompatible with the way Confluence handles pages.
The way confluence clients rename pages is the following: page = getPage(pageId); page.setSpace("New space"); page.setTitle("New title"); storePage(page);
In XWiki in order to rename a page we need to change its ID, and no client written for confluence will do this.
Currently the authoritative source for the page location is the ID (basically storePage ignores the space field) and changing the title will only affect the page title.
However if we agree to assume that the when using XMLRPC the semantics of the page title is that of the page name in an XWiki ID, we will be able to be confluence compatible.
I see the following cases:
Let P=(id, space, title) the definition of a page. Let CP be the current page and NP the page to be stored (i.e. the page passed to storePage):
1) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "NewSpace", "Title") Here it is clear that the user wants to "rename" the page by moving it to another space. So we rename the page to ("NewSpace.Name", "NewSpace", "Title")
2) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "NewSpace", "NewTitle"); Here it is also clear that we want to move the page to NewSpace but we have a problem about how to name the new page: NewSpace.Name or NewSpace.NewTitle? According to the assumption stated before, we rename the page and use NewTitle as the page name. The renamed page will have the NewSpace.NewTitle id. We also set the renamed page title to NewTitle.
3) CP=("Space.Name", "Space", "Title") NP=("Space.Name", "Space", "NewTitle"); Here we have an ambiguity. Does the user want to to rename the page or set its title? According to the assumption stated before we assume that the user wants to rename the page so we will rename the page to Space.NewTitle and set its title to NewTitle.
This solves the compatibility problem, but we have drawback: we need an extra method for simply changing the title without having the side effect of renaming the page.
However this is not a big deal because it will be XWiki specfic and XEclipse might use that call when it detects it is talking to an XWiki and the user simply wants to change the title. In Confluence such an operation would not make sense, so XEclipse will not even present the "change title" option when talking to a confluence server.
I think this solves the issue.
If this sound good to you I might start to modify the storePage method for implementing the new semantics.
WDYT?
Sounds good to me. It'll need to nicely documented in the code (like copy/pasting the explanation above in the code would be good). Thanks -Vincent
participants (2)
-
Fabio Mancinelli -
Vincent Massol