9 Jun
2008
9 Jun
'08
11:56 a.m.
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
9 Jun
9 Jun
12:12 p.m.
New subject: [xwiki-devs] Any other comments to XWIKI-2428 (renamePage method)?
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
2:16 p.m.
New subject: [xwiki-devs] Any other comments to XWIKI-2428 (renamePage method)?
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
2:29 p.m.
New subject: [xwiki-devs] Any other comments to XWIKI-2428 (renamePage method)?
On Jun 9, 2008, at 2:16 PM, Fabio Mancinelli wrote:
On 9 juin 08, at 12:12, Vincent Massol wrote:
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
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?
5996
days inactive
5996
days old
3 comments
2 participants
participants (2)
-
Fabio Mancinelli -
Vincent Massol