[xwiki-devs] about login and logout using XWiki REST API
Dear all, I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}. One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth. HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response. Therefore, do we need to implement login and logout methods? Best regards Jun Han
You certainly need it with XWiki session. In general, XWiki session is more secure because: - the login part can be made over https if needed - then, no password but only a session ID is exchange (typically bound to the IP) I agree it makes no sense to login with Basic Auth. paul Le 4 juin 2011 à 18:27, Jun Han a écrit :
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Paul, Thanks a lot for your reply. I think I kinda understand how Xwiki session is created when user logs in using a login form in a web browser. But I am not very clear about how to achieve the same function of XWiki session in XEclipse desktop application. An HTTP post request can be sent from XEclipse client and get a response with some session id. Then what would be the next step in XEclipse client? Save session id for the future request (in cookie or some other form) and pass it in some way (in HTTP header or as a form parameter) to the REST API along with the resource URL? Best regards Jun Han On 06/04/2011 04:56 PM, Paul Libbrecht wrote:
You certainly need it with XWiki session. In general, XWiki session is more secure because: - the login part can be made over https if needed - then, no password but only a session ID is exchange (typically bound to the IP) I agree it makes no sense to login with Basic Auth.
paul
Le 4 juin 2011 à 18:27, Jun Han a écrit :
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user. So what is usually done is to send basic-auth credentials with each request. You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests. The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project. -Fabio On Sat, Jun 4, 2011 at 6:27 PM, Jun Han <[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio, Thanks a lot for your clarification. I will go on implementing xwiki navigation panel. The current implementation of xwiki navigation panel's tree structure looks like: Wiki |--Spaces |--Pages Do we need to display the other xwiki resources, such as comments, tags, objects, attachments, in the navigation panel? Best regards Jun Han On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio, I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password. A status code of 200 will be regarded as successful while 401 means login fails. The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins. I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly. One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them? Best regards Jun Han On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, the REST api also takes into account Wikis, so you should take into account this into the plugin. -Fabio On Tue, Jun 7, 2011 at 7:35 AM, Jun Han <[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ 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
Hi Jun, On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like: xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc. 0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs. The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects. If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like: -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc. I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like: ------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc. Anyway, the main idea is to expose as much as REST API allows. Check again the API specs. You can get creative with the details on how to display/handle the new stuff. :) Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Eduard and Fabio, Thanks a lot for your suggestions. I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest. A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png Now the labels display the whole <href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names. It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace. Best regards Jun Han On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. Thanks, Fabio On Wed, Jun 8, 2011 at 10:26 PM, Jun Han <[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole <href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote:
Dear all,
I am on the way of replacing the xmlrpc implementation of RemoteXWikiDataStorage implements IDataStorage {}.
One question is about how to implement login and logout functionality via REST API. From REST API document, users can be authenticated via something like: 1. XWiki session 2. HTTP Basic Auth.
HTTP basic auth can be implemented via adding HTTP header to the HTTP request, then XEclipse can display Xwiki Resources by parsing the response.
Therefore, do we need to implement login and logout methods?
Best regards Jun Han _______________________________________________ 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
_______________________________________________ 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
Hi Jun, On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc. As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection. Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names. Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole<href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote:
Hi Jun,
login/logout can be implemented in order to store on the client side user credentials that are sent with HTTP requests. Currently there is no way in the REST-api to get a "session token" (like the cookie sent after a login is made using the web form) so that subsequent requests are performed on the behalf of a previously authenticated user.
So what is usually done is to send basic-auth credentials with each request.
You can start with this. Next you might try to retrieve the cookie by faking a standard login and using that cookie in subsequent requests.
The ideal setting would be to implement server side some OAuth-like mechanism, but this is out of scope wrt your project.
-Fabio
On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: > Dear all, > > I am on the way of replacing the xmlrpc implementation of > RemoteXWikiDataStorage implements IDataStorage {}. > > One question is about how to implement login and logout functionality > via REST API. > From REST API document, users can be authenticated via something like: > 1. XWiki session > 2. HTTP Basic Auth. > > HTTP basic auth can be implemented via adding HTTP header to the HTTP > request, then XEclipse can display Xwiki Resources by parsing the response. > > Therefore, do we need to implement login and logout methods? > > Best regards > Jun Han > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Eduard and Fabio, I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core. I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. Best regards Jun Han On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole<href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote:
Hi Fabio,
I have finished replacing xmlrpc implementation of login functionality by sending http GET request to entry point (http://localhost:8080/xwiki/rest/) along with username/password.
A status code of 200 will be regarded as successful while 401 means login fails.
The source code have been updated in org.xwiki.eclipse.ui and org.xwiki.eclipse.core plugins.
I will begin working on xwiki navigatoin panel and replace xmlrpc code accordingly.
One question is what resources are to be included in navigation panel, besides xwiki -> space -> pages? and how to display them?
Best regards
Jun Han
On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: > Hi Jun, > > login/logout can be implemented in order to store on the client side > user credentials that are sent with HTTP requests. > Currently there is no way in the REST-api to get a "session token" > (like the cookie sent after a login is made using the web form) so > that subsequent requests are performed on the behalf of a previously > authenticated user. > > So what is usually done is to send basic-auth credentials with each request. > > You can start with this. Next you might try to retrieve the cookie by > faking a standard login and using that cookie in subsequent requests. > > The ideal setting would be to implement server side some OAuth-like > mechanism, but this is out of scope wrt your project. > > -Fabio > > On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >> Dear all, >> >> I am on the way of replacing the xmlrpc implementation of >> RemoteXWikiDataStorage implements IDataStorage {}. >> >> One question is about how to implement login and logout functionality >> via REST API. >> From REST API document, users can be authenticated via something like: >> 1. XWiki session >> 2. HTTP Basic Auth. >> >> HTTP basic auth can be implemented via adding HTTP header to the HTTP >> request, then XEclipse can display Xwiki Resources by parsing the response. >> >> Therefore, do we need to implement login and logout methods? >> >> Best regards >> Jun Han >> _______________________________________________ >> 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly. We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC. Besides that, keep up the good work ;) Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole<href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote:
Hi Jun,
the REST api also takes into account Wikis, so you should take into account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard
-Fabio
On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: > Hi Fabio, > > I have finished replacing xmlrpc implementation of login functionality > by sending http GET request to entry point > (http://localhost:8080/xwiki/rest/) along with username/password. > > A status code of 200 will be regarded as successful while 401 means > login fails. > > The source code have been updated in org.xwiki.eclipse.ui and > org.xwiki.eclipse.core plugins. > > I will begin working on xwiki navigatoin panel and replace xmlrpc code > accordingly. > > One question is what resources are to be included in navigation panel, > besides xwiki -> space -> pages? and how to display them? > > Best regards > > Jun Han > > On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >> Hi Jun, >> >> login/logout can be implemented in order to store on the client side >> user credentials that are sent with HTTP requests. >> Currently there is no way in the REST-api to get a "session token" >> (like the cookie sent after a login is made using the web form) so >> that subsequent requests are performed on the behalf of a previously >> authenticated user. >> >> So what is usually done is to send basic-auth credentials with each request. >> >> You can start with this. Next you might try to retrieve the cookie by >> faking a standard login and using that cookie in subsequent requests. >> >> The ideal setting would be to implement server side some OAuth-like >> mechanism, but this is out of scope wrt your project. >> >> -Fabio >> >> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> I am on the way of replacing the xmlrpc implementation of >>> RemoteXWikiDataStorage implements IDataStorage {}. >>> >>> One question is about how to implement login and logout functionality >>> via REST API. >>> From REST API document, users can be authenticated via something like: >>> 1. XWiki session >>> 2. HTTP Basic Auth. >>> >>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>> request, then XEclipse can display Xwiki Resources by parsing the response. >>> >>> Therefore, do we need to implement login and logout methods? >>> >>> Best regards >>> Jun Han >>> _______________________________________________ >>> 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 > _______________________________________________ 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
_______________________________________________ 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
Hi Eduard, Thanks a lot for prompt instruction. I forgot to sync the screenshot to the server. Now it is the correct one. Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them. For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey) They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest. If this is the way to go, I will look more into how to implement this. Adapter pattern may be used. Best regards Jun Han On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole<href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote:
Hi Jun,
On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: > Hi Jun, > > the REST api also takes into account Wikis, so you should take into > account this into the plugin. Also, I think that we need to display the other resources (like we do now), but maybe we should improve that too.
I`d suggest that we group objects by class name, something like:
xwiki.org (wiki/farm/connection name, given by the user) -- xwiki (main/sub wiki name) ---- Main ------ WebHome -------- XWiki.XWikiComments ---------- 0 ---------- 1 ---------- 2 -------- XWiki.MyClass ---------- 0 ---------- 1 etc.
0, 1, 2 above are object numbers, but, in the future, they might change to some other IDs.
The advantage of such an ordering is that, highly used pages (that have lots of comments, or lots of objects of specific classes) will allow easier management of the objects.
If a list of numbers looks too blank, you could have them print the value of the first property it their class, just like XWiki`s object editor does and you`d have something like:
-------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
I don`t know what's the status of Attachments (I don remember if we display them or not), but we should have them as an 'implicit' first class like:
------ WebHome -------- Attachments ---------- dog.png ---------- spreadsheet.xls -------- XWiki.XWikiComments ---------- 0 : Administrator ('author' property value) ---------- 1 : Guest ---------- 2 : Administrator -------- XWiki.MyClass ---------- 0 : etc. ---------- 1 : etc. etc.
Anyway, the main idea is to expose as much as REST API allows. Check again the API specs.
You can get creative with the details on how to display/handle the new stuff. :)
Cheers, Eduard > -Fabio > > On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >> Hi Fabio, >> >> I have finished replacing xmlrpc implementation of login functionality >> by sending http GET request to entry point >> (http://localhost:8080/xwiki/rest/) along with username/password. >> >> A status code of 200 will be regarded as successful while 401 means >> login fails. >> >> The source code have been updated in org.xwiki.eclipse.ui and >> org.xwiki.eclipse.core plugins. >> >> I will begin working on xwiki navigatoin panel and replace xmlrpc code >> accordingly. >> >> One question is what resources are to be included in navigation panel, >> besides xwiki -> space -> pages? and how to display them? >> >> Best regards >> >> Jun Han >> >> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> login/logout can be implemented in order to store on the client side >>> user credentials that are sent with HTTP requests. >>> Currently there is no way in the REST-api to get a "session token" >>> (like the cookie sent after a login is made using the web form) so >>> that subsequent requests are performed on the behalf of a previously >>> authenticated user. >>> >>> So what is usually done is to send basic-auth credentials with each request. >>> >>> You can start with this. Next you might try to retrieve the cookie by >>> faking a standard login and using that cookie in subsequent requests. >>> >>> The ideal setting would be to implement server side some OAuth-like >>> mechanism, but this is out of scope wrt your project. >>> >>> -Fabio >>> >>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>> Dear all, >>>> >>>> I am on the way of replacing the xmlrpc implementation of >>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>> >>>> One question is about how to implement login and logout functionality >>>> via REST API. >>>> From REST API document, users can be authenticated via something like: >>>> 1. XWiki session >>>> 2. HTTP Basic Auth. >>>> >>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>> >>>> Therefore, do we need to implement login and logout methods? >>>> >>>> Best regards >>>> Jun Han >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc. So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page) Cheers, Eduard On Fri, Jun 10, 2011 at 7:52 PM, Jun Han <[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote:
Hi Eduard and Fabio,
Thanks a lot for your suggestions.
I managed to create a top-level tree expansion when user requests the entry point of REST API: localhost:8080/xwiki/rest.
A screenshot is available at: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png
Now the labels display the whole<href> attribute, I plan to "syntaxes" and "wikis" later on. When user clicks the "wikis", the navigation tree will continue to expand to show all the sub-wiki names.
It took me a while to figure out the configuration of tree content provider, tree viewer and label provider, which is a little different with what I did in Eclipse SWT development. As this has been sorted out, I would pick up the pace.
Best regards Jun Han
On 06/07/2011 10:37 AM, Eduard Moraru wrote: > Hi Jun, > > On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >> Hi Jun, >> >> the REST api also takes into account Wikis, so you should take into >> account this into the plugin. > Also, I think that we need to display the other resources (like we do > now), but maybe we should improve that too. > > I`d suggest that we group objects by class name, something like: > > xwiki.org (wiki/farm/connection name, given by the user) > -- xwiki (main/sub wiki name) > ---- Main > ------ WebHome > -------- XWiki.XWikiComments > ---------- 0 > ---------- 1 > ---------- 2 > -------- XWiki.MyClass > ---------- 0 > ---------- 1 > etc. > > 0, 1, 2 above are object numbers, but, in the future, they might change > to some other IDs. > > The advantage of such an ordering is that, highly used pages (that have > lots of comments, or lots of objects of specific classes) will allow > easier management of the objects. > > If a list of numbers looks too blank, you could have them print the > value of the first property it their class, just like XWiki`s object > editor does and you`d have something like: > > -------- XWiki.XWikiComments > ---------- 0 : Administrator ('author' property value) > ---------- 1 : Guest > ---------- 2 : Administrator > -------- XWiki.MyClass > ---------- 0 : etc. > ---------- 1 : etc. > etc. > > I don`t know what's the status of Attachments (I don remember if we > display them or not), but we should have them as an 'implicit' first > class like: > > ------ WebHome > -------- Attachments > ---------- dog.png > ---------- spreadsheet.xls > -------- XWiki.XWikiComments > ---------- 0 : Administrator ('author' property value) > ---------- 1 : Guest > ---------- 2 : Administrator > -------- XWiki.MyClass > ---------- 0 : etc. > ---------- 1 : etc. > etc. > > Anyway, the main idea is to expose as much as REST API allows. Check > again the API specs. > > You can get creative with the details on how to display/handle the new > stuff. :) > > Cheers, > Eduard >> -Fabio >> >> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>> Hi Fabio, >>> >>> I have finished replacing xmlrpc implementation of login functionality >>> by sending http GET request to entry point >>> (http://localhost:8080/xwiki/rest/) along with username/password. >>> >>> A status code of 200 will be regarded as successful while 401 means >>> login fails. >>> >>> The source code have been updated in org.xwiki.eclipse.ui and >>> org.xwiki.eclipse.core plugins. >>> >>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>> accordingly. >>> >>> One question is what resources are to be included in navigation panel, >>> besides xwiki -> space -> pages? and how to display them? >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> login/logout can be implemented in order to store on the client side >>>> user credentials that are sent with HTTP requests. >>>> Currently there is no way in the REST-api to get a "session token" >>>> (like the cookie sent after a login is made using the web form) so >>>> that subsequent requests are performed on the behalf of a previously >>>> authenticated user. >>>> >>>> So what is usually done is to send basic-auth credentials with each request. >>>> >>>> You can start with this. Next you might try to retrieve the cookie by >>>> faking a standard login and using that cookie in subsequent requests. >>>> >>>> The ideal setting would be to implement server side some OAuth-like >>>> mechanism, but this is out of scope wrt your project. >>>> >>>> -Fabio >>>> >>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>> Dear all, >>>>> >>>>> I am on the way of replacing the xmlrpc implementation of >>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>> >>>>> One question is about how to implement login and logout functionality >>>>> via REST API. >>>>> From REST API document, users can be authenticated via something like: >>>>> 1. XWiki session >>>>> 2. HTTP Basic Auth. >>>>> >>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>> >>>>> Therefore, do we need to implement login and logout methods? >>>>> >>>>> Best regards >>>>> Jun Han >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear all, After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation. Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions. If my understanding is correct, I will begin re-factoring work. Best regards Jun Han On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote:
Hi Jun,
I am not sure that syntaxes should appear as a child of connection. I would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard
Thanks, Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: > Hi Eduard and Fabio, > > Thanks a lot for your suggestions. > > I managed to create a top-level tree expansion when user requests the > entry point of REST API: localhost:8080/xwiki/rest. > > A screenshot is available at: > http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png > > Now the labels display the whole<href> attribute, I plan to "syntaxes" > and "wikis" later on. > When user clicks the "wikis", the navigation tree will continue to > expand to show all the sub-wiki names. > > It took me a while to figure out the configuration of tree content > provider, tree viewer and label provider, which is a little different > with what I did in Eclipse SWT development. As this has been sorted out, > I would pick up the pace. > > Best regards > Jun Han > > On 06/07/2011 10:37 AM, Eduard Moraru wrote: >> Hi Jun, >> >> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> the REST api also takes into account Wikis, so you should take into >>> account this into the plugin. >> Also, I think that we need to display the other resources (like we do >> now), but maybe we should improve that too. >> >> I`d suggest that we group objects by class name, something like: >> >> xwiki.org (wiki/farm/connection name, given by the user) >> -- xwiki (main/sub wiki name) >> ---- Main >> ------ WebHome >> -------- XWiki.XWikiComments >> ---------- 0 >> ---------- 1 >> ---------- 2 >> -------- XWiki.MyClass >> ---------- 0 >> ---------- 1 >> etc. >> >> 0, 1, 2 above are object numbers, but, in the future, they might change >> to some other IDs. >> >> The advantage of such an ordering is that, highly used pages (that have >> lots of comments, or lots of objects of specific classes) will allow >> easier management of the objects. >> >> If a list of numbers looks too blank, you could have them print the >> value of the first property it their class, just like XWiki`s object >> editor does and you`d have something like: >> >> -------- XWiki.XWikiComments >> ---------- 0 : Administrator ('author' property value) >> ---------- 1 : Guest >> ---------- 2 : Administrator >> -------- XWiki.MyClass >> ---------- 0 : etc. >> ---------- 1 : etc. >> etc. >> >> I don`t know what's the status of Attachments (I don remember if we >> display them or not), but we should have them as an 'implicit' first >> class like: >> >> ------ WebHome >> -------- Attachments >> ---------- dog.png >> ---------- spreadsheet.xls >> -------- XWiki.XWikiComments >> ---------- 0 : Administrator ('author' property value) >> ---------- 1 : Guest >> ---------- 2 : Administrator >> -------- XWiki.MyClass >> ---------- 0 : etc. >> ---------- 1 : etc. >> etc. >> >> Anyway, the main idea is to expose as much as REST API allows. Check >> again the API specs. >> >> You can get creative with the details on how to display/handle the new >> stuff. :) >> >> Cheers, >> Eduard >>> -Fabio >>> >>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>> Hi Fabio, >>>> >>>> I have finished replacing xmlrpc implementation of login functionality >>>> by sending http GET request to entry point >>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>> >>>> A status code of 200 will be regarded as successful while 401 means >>>> login fails. >>>> >>>> The source code have been updated in org.xwiki.eclipse.ui and >>>> org.xwiki.eclipse.core plugins. >>>> >>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>> accordingly. >>>> >>>> One question is what resources are to be included in navigation panel, >>>> besides xwiki -> space -> pages? and how to display them? >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>> Hi Jun, >>>>> >>>>> login/logout can be implemented in order to store on the client side >>>>> user credentials that are sent with HTTP requests. >>>>> Currently there is no way in the REST-api to get a "session token" >>>>> (like the cookie sent after a login is made using the web form) so >>>>> that subsequent requests are performed on the behalf of a previously >>>>> authenticated user. >>>>> >>>>> So what is usually done is to send basic-auth credentials with each request. >>>>> You can start with this. Next you might try to retrieve the cookie by >>>>> faking a standard login and using that cookie in subsequent requests. >>>>> The ideal setting would be to implement server side some OAuth-like >>>>> mechanism, but this is out of scope wrt your project. >>>>> >>>>> -Fabio >>>>> >>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>> Dear all, >>>>>> >>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>> >>>>>> One question is about how to implement login and logout functionality >>>>>> via REST API. >>>>>> From REST API document, users can be authenticated via something like: >>>>>> 1. XWiki session >>>>>> 2. HTTP Basic Auth. >>>>>> >>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>> Therefore, do we need to implement login and logout methods? >>>>>> >>>>>> Best regards >>>>>> Jun Han >>>>>> _______________________________________________ >>>>>> 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 >>>> >>> _______________________________________________ >>> 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 > _______________________________________________ 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
_______________________________________________ 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
Hi Jun, On 06/13/2011 10:00 AM, Jun Han wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han +1, sounds good.
First note: You`ll also need to take care of features available in one implementation and not available in the others. The list of features should always be the most extensive (the one supported by the latest XWiki-supported back-end, in our current case, rest) and it should be reflected in the abstract layer. The implementations that don`t support a feature will just fake it or return null, depending on the case. For example, in xmlrpc, if connected to wiki X and you call getWikis, it will just return X (faking it by returning only what it knows). Second note: Maybe you`re already aware of this, but please make sure to respect http://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle for all the code you write so that it's easier to read/integrate it with the existing code. Good luck, Eduard
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: > Hi Jun, > > I am not sure that syntaxes should appear as a child of connection. I > would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard > Thanks, > Fabio > > On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >> Hi Eduard and Fabio, >> >> Thanks a lot for your suggestions. >> >> I managed to create a top-level tree expansion when user requests the >> entry point of REST API: localhost:8080/xwiki/rest. >> >> A screenshot is available at: >> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >> >> Now the labels display the whole<href> attribute, I plan to "syntaxes" >> and "wikis" later on. >> When user clicks the "wikis", the navigation tree will continue to >> expand to show all the sub-wiki names. >> >> It took me a while to figure out the configuration of tree content >> provider, tree viewer and label provider, which is a little different >> with what I did in Eclipse SWT development. As this has been sorted out, >> I would pick up the pace. >> >> Best regards >> Jun Han >> >> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> the REST api also takes into account Wikis, so you should take into >>>> account this into the plugin. >>> Also, I think that we need to display the other resources (like we do >>> now), but maybe we should improve that too. >>> >>> I`d suggest that we group objects by class name, something like: >>> >>> xwiki.org (wiki/farm/connection name, given by the user) >>> -- xwiki (main/sub wiki name) >>> ---- Main >>> ------ WebHome >>> -------- XWiki.XWikiComments >>> ---------- 0 >>> ---------- 1 >>> ---------- 2 >>> -------- XWiki.MyClass >>> ---------- 0 >>> ---------- 1 >>> etc. >>> >>> 0, 1, 2 above are object numbers, but, in the future, they might change >>> to some other IDs. >>> >>> The advantage of such an ordering is that, highly used pages (that have >>> lots of comments, or lots of objects of specific classes) will allow >>> easier management of the objects. >>> >>> If a list of numbers looks too blank, you could have them print the >>> value of the first property it their class, just like XWiki`s object >>> editor does and you`d have something like: >>> >>> -------- XWiki.XWikiComments >>> ---------- 0 : Administrator ('author' property value) >>> ---------- 1 : Guest >>> ---------- 2 : Administrator >>> -------- XWiki.MyClass >>> ---------- 0 : etc. >>> ---------- 1 : etc. >>> etc. >>> >>> I don`t know what's the status of Attachments (I don remember if we >>> display them or not), but we should have them as an 'implicit' first >>> class like: >>> >>> ------ WebHome >>> -------- Attachments >>> ---------- dog.png >>> ---------- spreadsheet.xls >>> -------- XWiki.XWikiComments >>> ---------- 0 : Administrator ('author' property value) >>> ---------- 1 : Guest >>> ---------- 2 : Administrator >>> -------- XWiki.MyClass >>> ---------- 0 : etc. >>> ---------- 1 : etc. >>> etc. >>> >>> Anyway, the main idea is to expose as much as REST API allows. Check >>> again the API specs. >>> >>> You can get creative with the details on how to display/handle the new >>> stuff. :) >>> >>> Cheers, >>> Eduard >>>> -Fabio >>>> >>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>> Hi Fabio, >>>>> >>>>> I have finished replacing xmlrpc implementation of login functionality >>>>> by sending http GET request to entry point >>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>> >>>>> A status code of 200 will be regarded as successful while 401 means >>>>> login fails. >>>>> >>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>> org.xwiki.eclipse.core plugins. >>>>> >>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>> accordingly. >>>>> >>>>> One question is what resources are to be included in navigation panel, >>>>> besides xwiki -> space -> pages? and how to display them? >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> login/logout can be implemented in order to store on the client side >>>>>> user credentials that are sent with HTTP requests. >>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>> (like the cookie sent after a login is made using the web form) so >>>>>> that subsequent requests are performed on the behalf of a previously >>>>>> authenticated user. >>>>>> >>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>> mechanism, but this is out of scope wrt your project. >>>>>> >>>>>> -Fabio >>>>>> >>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>> >>>>>>> One question is about how to implement login and logout functionality >>>>>>> via REST API. >>>>>>> From REST API document, users can be authenticated via something like: >>>>>>> 1. XWiki session >>>>>>> 2. HTTP Basic Auth. >>>>>>> >>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>> >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!) Midterm is approaching so we need to make things advance a little bit faster. Thanks, Fabio On Mon, Jun 13, 2011 at 9:00 AM, Jun Han <[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote:
Hi Jun,
On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: > Hi Jun, > > I am not sure that syntaxes should appear as a child of connection. I > would show this information in the property panel of the connection. I think that you should make the "wikis" implicit as well and leave only the Connection Name as top root, just like in my previous proposal:
Connection01 - wiki1 -- spaceA --- pageX - wiki2 - etc.
As Fabio pointed out, stuff like supported syntaxes and xwiki version should be displayed in the properties page of a connection.
Also, you need to take care when the user enters the user name and password and consider the wiki for which it applies. User Admin on the main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 (subwiki1:XWiki.Admin). I believe that, if you don`t enter the absolute user name (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it will be resolved to the wiki of the resource you are trying to access. You should, at least internally, always use absolute user names.
Thanks, Eduard > Thanks, > Fabio > > On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >> Hi Eduard and Fabio, >> >> Thanks a lot for your suggestions. >> >> I managed to create a top-level tree expansion when user requests the >> entry point of REST API: localhost:8080/xwiki/rest. >> >> A screenshot is available at: >> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >> >> Now the labels display the whole<href> attribute, I plan to "syntaxes" >> and "wikis" later on. >> When user clicks the "wikis", the navigation tree will continue to >> expand to show all the sub-wiki names. >> >> It took me a while to figure out the configuration of tree content >> provider, tree viewer and label provider, which is a little different >> with what I did in Eclipse SWT development. As this has been sorted out, >> I would pick up the pace. >> >> Best regards >> Jun Han >> >> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> the REST api also takes into account Wikis, so you should take into >>>> account this into the plugin. >>> Also, I think that we need to display the other resources (like we do >>> now), but maybe we should improve that too. >>> >>> I`d suggest that we group objects by class name, something like: >>> >>> xwiki.org (wiki/farm/connection name, given by the user) >>> -- xwiki (main/sub wiki name) >>> ---- Main >>> ------ WebHome >>> -------- XWiki.XWikiComments >>> ---------- 0 >>> ---------- 1 >>> ---------- 2 >>> -------- XWiki.MyClass >>> ---------- 0 >>> ---------- 1 >>> etc. >>> >>> 0, 1, 2 above are object numbers, but, in the future, they might change >>> to some other IDs. >>> >>> The advantage of such an ordering is that, highly used pages (that have >>> lots of comments, or lots of objects of specific classes) will allow >>> easier management of the objects. >>> >>> If a list of numbers looks too blank, you could have them print the >>> value of the first property it their class, just like XWiki`s object >>> editor does and you`d have something like: >>> >>> -------- XWiki.XWikiComments >>> ---------- 0 : Administrator ('author' property value) >>> ---------- 1 : Guest >>> ---------- 2 : Administrator >>> -------- XWiki.MyClass >>> ---------- 0 : etc. >>> ---------- 1 : etc. >>> etc. >>> >>> I don`t know what's the status of Attachments (I don remember if we >>> display them or not), but we should have them as an 'implicit' first >>> class like: >>> >>> ------ WebHome >>> -------- Attachments >>> ---------- dog.png >>> ---------- spreadsheet.xls >>> -------- XWiki.XWikiComments >>> ---------- 0 : Administrator ('author' property value) >>> ---------- 1 : Guest >>> ---------- 2 : Administrator >>> -------- XWiki.MyClass >>> ---------- 0 : etc. >>> ---------- 1 : etc. >>> etc. >>> >>> Anyway, the main idea is to expose as much as REST API allows. Check >>> again the API specs. >>> >>> You can get creative with the details on how to display/handle the new >>> stuff. :) >>> >>> Cheers, >>> Eduard >>>> -Fabio >>>> >>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>> Hi Fabio, >>>>> >>>>> I have finished replacing xmlrpc implementation of login functionality >>>>> by sending http GET request to entry point >>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>> >>>>> A status code of 200 will be regarded as successful while 401 means >>>>> login fails. >>>>> >>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>> org.xwiki.eclipse.core plugins. >>>>> >>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>> accordingly. >>>>> >>>>> One question is what resources are to be included in navigation panel, >>>>> besides xwiki -> space -> pages? and how to display them? >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> login/logout can be implemented in order to store on the client side >>>>>> user credentials that are sent with HTTP requests. >>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>> (like the cookie sent after a login is made using the web form) so >>>>>> that subsequent requests are performed on the behalf of a previously >>>>>> authenticated user. >>>>>> >>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>> mechanism, but this is out of scope wrt your project. >>>>>> >>>>>> -Fabio >>>>>> >>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>> >>>>>>> One question is about how to implement login and logout functionality >>>>>>> via REST API. >>>>>>> From REST API document, users can be authenticated via something like: >>>>>>> 1. XWiki session >>>>>>> 2. HTTP Basic Auth. >>>>>>> >>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>> >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> > _______________________________________________ > 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio, I just committed the work of branch to master a moment ago. Some previous commits are lost and the git repository (junhan / xwiki-eclipse) has been deleted and re-created because the rest implementation and xmlrpc one were mixed together. A more detailed system diagram is shown in http://dl.dropbox.com/u/3466762/xwiki/system%20diagram.png. I thought of using two separate plugins (model and storage), however, as circular dependency exists between the two, I put them into one plugin, called xwiki.eclipse.storage. In this way, xmlrpc and rest backend implementations will depend on xwiki.eclipse.storage and ui plugin will not have direct dependency on specific xmlprc code or library. The re-factor work is 95% done. Two classes in ui still have xmlrpc dependency, and I am now considering a suitable way to handle that. The rcp application can launch successfully. I will continue to test the functions of xmlrpc plugin. When it is done, I will initialize a pull request. Best regards Jun Han On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote: > Hi Jun, > > On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> I am not sure that syntaxes should appear as a child of connection. I >> would show this information in the property panel of the connection. > I think that you should make the "wikis" implicit as well and leave only > the Connection Name as top root, just like in my previous proposal: > > Connection01 > - wiki1 > -- spaceA > --- pageX > - wiki2 > - etc. > > As Fabio pointed out, stuff like supported syntaxes and xwiki version > should be displayed in the properties page of a connection. > > Also, you need to take care when the user enters the user name and > password and consider the wiki for which it applies. User Admin on the > main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 > (subwiki1:XWiki.Admin). > I believe that, if you don`t enter the absolute user name > (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it > will be resolved to the wiki of the resource you are trying to access. > You should, at least internally, always use absolute user names. > > Thanks, > Eduard >> Thanks, >> Fabio >> >> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >>> Hi Eduard and Fabio, >>> >>> Thanks a lot for your suggestions. >>> >>> I managed to create a top-level tree expansion when user requests the >>> entry point of REST API: localhost:8080/xwiki/rest. >>> >>> A screenshot is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>> >>> Now the labels display the whole<href> attribute, I plan to "syntaxes" >>> and "wikis" later on. >>> When user clicks the "wikis", the navigation tree will continue to >>> expand to show all the sub-wiki names. >>> >>> It took me a while to figure out the configuration of tree content >>> provider, tree viewer and label provider, which is a little different >>> with what I did in Eclipse SWT development. As this has been sorted out, >>> I would pick up the pace. >>> >>> Best regards >>> Jun Han >>> >>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>> Hi Jun, >>>>> >>>>> the REST api also takes into account Wikis, so you should take into >>>>> account this into the plugin. >>>> Also, I think that we need to display the other resources (like we do >>>> now), but maybe we should improve that too. >>>> >>>> I`d suggest that we group objects by class name, something like: >>>> >>>> xwiki.org (wiki/farm/connection name, given by the user) >>>> -- xwiki (main/sub wiki name) >>>> ---- Main >>>> ------ WebHome >>>> -------- XWiki.XWikiComments >>>> ---------- 0 >>>> ---------- 1 >>>> ---------- 2 >>>> -------- XWiki.MyClass >>>> ---------- 0 >>>> ---------- 1 >>>> etc. >>>> >>>> 0, 1, 2 above are object numbers, but, in the future, they might change >>>> to some other IDs. >>>> >>>> The advantage of such an ordering is that, highly used pages (that have >>>> lots of comments, or lots of objects of specific classes) will allow >>>> easier management of the objects. >>>> >>>> If a list of numbers looks too blank, you could have them print the >>>> value of the first property it their class, just like XWiki`s object >>>> editor does and you`d have something like: >>>> >>>> -------- XWiki.XWikiComments >>>> ---------- 0 : Administrator ('author' property value) >>>> ---------- 1 : Guest >>>> ---------- 2 : Administrator >>>> -------- XWiki.MyClass >>>> ---------- 0 : etc. >>>> ---------- 1 : etc. >>>> etc. >>>> >>>> I don`t know what's the status of Attachments (I don remember if we >>>> display them or not), but we should have them as an 'implicit' first >>>> class like: >>>> >>>> ------ WebHome >>>> -------- Attachments >>>> ---------- dog.png >>>> ---------- spreadsheet.xls >>>> -------- XWiki.XWikiComments >>>> ---------- 0 : Administrator ('author' property value) >>>> ---------- 1 : Guest >>>> ---------- 2 : Administrator >>>> -------- XWiki.MyClass >>>> ---------- 0 : etc. >>>> ---------- 1 : etc. >>>> etc. >>>> >>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>> again the API specs. >>>> >>>> You can get creative with the details on how to display/handle the new >>>> stuff. :) >>>> >>>> Cheers, >>>> Eduard >>>>> -Fabio >>>>> >>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>>> Hi Fabio, >>>>>> >>>>>> I have finished replacing xmlrpc implementation of login functionality >>>>>> by sending http GET request to entry point >>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>> >>>>>> A status code of 200 will be regarded as successful while 401 means >>>>>> login fails. >>>>>> >>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>> org.xwiki.eclipse.core plugins. >>>>>> >>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>>> accordingly. >>>>>> >>>>>> One question is what resources are to be included in navigation panel, >>>>>> besides xwiki -> space -> pages? and how to display them? >>>>>> Best regards >>>>>> >>>>>> Jun Han >>>>>> >>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> login/logout can be implemented in order to store on the client side >>>>>>> user credentials that are sent with HTTP requests. >>>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>>> (like the cookie sent after a login is made using the web form) so >>>>>>> that subsequent requests are performed on the behalf of a previously >>>>>>> authenticated user. >>>>>>> >>>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>> >>>>>>> -Fabio >>>>>>> >>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>> >>>>>>>> One question is about how to implement login and logout functionality >>>>>>>> via REST API. >>>>>>>> From REST API document, users can be authenticated via something like: >>>>>>>> 1. XWiki session >>>>>>>> 2. HTTP Basic Auth. >>>>>>>> >>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>> >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio, I have already finished re-factoring the whole xmlrpc backend. A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. I will continue working on the rest backend following the previous discussion. Best regards Jun Han On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote:
Hi, Eduard and Fabio,
I finished part of the navigation panel, which shows the connection, wiki, space. Please see the screenshot at http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. Adding pages under space is straightforward too, however, it requires re-factor a lot of source code, which spreads in the plugin of xwiki.eclipse.ui and xwiki.eclipse.core.
I will continue work on displaying more XWiki resources after I finish re-factoring the properties editor, action provider (context menu), and other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard
Best regards Jun Han
On 06/09/2011 07:26 PM, Eduard Moraru wrote: > Hi Jun, > > On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> I am not sure that syntaxes should appear as a child of connection. I >> would show this information in the property panel of the connection. > I think that you should make the "wikis" implicit as well and leave only > the Connection Name as top root, just like in my previous proposal: > > Connection01 > - wiki1 > -- spaceA > --- pageX > - wiki2 > - etc. > > As Fabio pointed out, stuff like supported syntaxes and xwiki version > should be displayed in the properties page of a connection. > > Also, you need to take care when the user enters the user name and > password and consider the wiki for which it applies. User Admin on the > main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 > (subwiki1:XWiki.Admin). > I believe that, if you don`t enter the absolute user name > (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it > will be resolved to the wiki of the resource you are trying to access. > You should, at least internally, always use absolute user names. > > Thanks, > Eduard >> Thanks, >> Fabio >> >> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >>> Hi Eduard and Fabio, >>> >>> Thanks a lot for your suggestions. >>> >>> I managed to create a top-level tree expansion when user requests the >>> entry point of REST API: localhost:8080/xwiki/rest. >>> >>> A screenshot is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>> >>> Now the labels display the whole<href> attribute, I plan to "syntaxes" >>> and "wikis" later on. >>> When user clicks the "wikis", the navigation tree will continue to >>> expand to show all the sub-wiki names. >>> >>> It took me a while to figure out the configuration of tree content >>> provider, tree viewer and label provider, which is a little different >>> with what I did in Eclipse SWT development. As this has been sorted out, >>> I would pick up the pace. >>> >>> Best regards >>> Jun Han >>> >>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>> Hi Jun, >>>>> >>>>> the REST api also takes into account Wikis, so you should take into >>>>> account this into the plugin. >>>> Also, I think that we need to display the other resources (like we do >>>> now), but maybe we should improve that too. >>>> >>>> I`d suggest that we group objects by class name, something like: >>>> >>>> xwiki.org (wiki/farm/connection name, given by the user) >>>> -- xwiki (main/sub wiki name) >>>> ---- Main >>>> ------ WebHome >>>> -------- XWiki.XWikiComments >>>> ---------- 0 >>>> ---------- 1 >>>> ---------- 2 >>>> -------- XWiki.MyClass >>>> ---------- 0 >>>> ---------- 1 >>>> etc. >>>> >>>> 0, 1, 2 above are object numbers, but, in the future, they might change >>>> to some other IDs. >>>> >>>> The advantage of such an ordering is that, highly used pages (that have >>>> lots of comments, or lots of objects of specific classes) will allow >>>> easier management of the objects. >>>> >>>> If a list of numbers looks too blank, you could have them print the >>>> value of the first property it their class, just like XWiki`s object >>>> editor does and you`d have something like: >>>> >>>> -------- XWiki.XWikiComments >>>> ---------- 0 : Administrator ('author' property value) >>>> ---------- 1 : Guest >>>> ---------- 2 : Administrator >>>> -------- XWiki.MyClass >>>> ---------- 0 : etc. >>>> ---------- 1 : etc. >>>> etc. >>>> >>>> I don`t know what's the status of Attachments (I don remember if we >>>> display them or not), but we should have them as an 'implicit' first >>>> class like: >>>> >>>> ------ WebHome >>>> -------- Attachments >>>> ---------- dog.png >>>> ---------- spreadsheet.xls >>>> -------- XWiki.XWikiComments >>>> ---------- 0 : Administrator ('author' property value) >>>> ---------- 1 : Guest >>>> ---------- 2 : Administrator >>>> -------- XWiki.MyClass >>>> ---------- 0 : etc. >>>> ---------- 1 : etc. >>>> etc. >>>> >>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>> again the API specs. >>>> >>>> You can get creative with the details on how to display/handle the new >>>> stuff. :) >>>> >>>> Cheers, >>>> Eduard >>>>> -Fabio >>>>> >>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>>> Hi Fabio, >>>>>> >>>>>> I have finished replacing xmlrpc implementation of login functionality >>>>>> by sending http GET request to entry point >>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>> >>>>>> A status code of 200 will be regarded as successful while 401 means >>>>>> login fails. >>>>>> >>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>> org.xwiki.eclipse.core plugins. >>>>>> >>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>>> accordingly. >>>>>> >>>>>> One question is what resources are to be included in navigation panel, >>>>>> besides xwiki -> space -> pages? and how to display them? >>>>>> Best regards >>>>>> >>>>>> Jun Han >>>>>> >>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> login/logout can be implemented in order to store on the client side >>>>>>> user credentials that are sent with HTTP requests. >>>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>>> (like the cookie sent after a login is made using the web form) so >>>>>>> that subsequent requests are performed on the behalf of a previously >>>>>>> authenticated user. >>>>>>> >>>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>> >>>>>>> -Fabio >>>>>>> >>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>>> Dear all, >>>>>>>> >>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>> >>>>>>>> One question is about how to implement login and logout functionality >>>>>>>> via REST API. >>>>>>>> From REST API document, users can be authenticated via something like: >>>>>>>> 1. XWiki session >>>>>>>> 2. HTTP Basic Auth. >>>>>>>> >>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>> >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> _______________________________________________ >> 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
_______________________________________________ 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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi there, I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends? IMO we should only use one and use the REST API only. If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote:
Hi Jun,
On 06/10/2011 05:26 PM, Jun Han wrote: > Hi, Eduard and Fabio, > > I finished part of the navigation panel, which shows the connection, > wiki, space. > Please see the screenshot at > http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. > Adding pages under space is straightforward too, however, it requires > re-factor a lot of source code, which spreads in the plugin of > xwiki.eclipse.ui and xwiki.eclipse.core. > > I will continue work on displaying more XWiki resources after I finish > re-factoring the properties editor, action provider (context menu), and > other dialog windows related to connection, wiki, space. It should not take that much of a refactoring on the UI part, since the heavy lifting is done in the core.
What I actually wanted to tell you is that you should take the refactoring in a modular direction and consider your work as a contribution and alternative for the existing system and not only as a replacement. I you can`t do it as a contribution, consider adding a mechanism that allows you to do so (see our first discussions on integrating the rest back-end). Keep the abstraction layer (interfaces, model, etc) as the main think the ui and even core components communicate with and keep the implementation of that abstraction layer pluggable (xml-rpc, rest, etc). The UI must also be aware of this and act accordingly.
We don`t want to do the same replacement work if, for whatever reason, we want to switch to a different back-end in the future. So keep that in mind at all time during GSoC.
Besides that, keep up the good work ;)
Thanks, Eduard > Best regards > Jun Han > > On 06/09/2011 07:26 PM, Eduard Moraru wrote: >> Hi Jun, >> >> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> I am not sure that syntaxes should appear as a child of connection. I >>> would show this information in the property panel of the connection. >> I think that you should make the "wikis" implicit as well and leave only >> the Connection Name as top root, just like in my previous proposal: >> >> Connection01 >> - wiki1 >> -- spaceA >> --- pageX >> - wiki2 >> - etc. >> >> As Fabio pointed out, stuff like supported syntaxes and xwiki version >> should be displayed in the properties page of a connection. >> >> Also, you need to take care when the user enters the user name and >> password and consider the wiki for which it applies. User Admin on the >> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >> (subwiki1:XWiki.Admin). >> I believe that, if you don`t enter the absolute user name >> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >> will be resolved to the wiki of the resource you are trying to access. >> You should, at least internally, always use absolute user names. >> >> Thanks, >> Eduard >>> Thanks, >>> Fabio >>> >>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >>>> Hi Eduard and Fabio, >>>> >>>> Thanks a lot for your suggestions. >>>> >>>> I managed to create a top-level tree expansion when user requests the >>>> entry point of REST API: localhost:8080/xwiki/rest. >>>> >>>> A screenshot is available at: >>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>> >>>> Now the labels display the whole<href> attribute, I plan to "syntaxes" >>>> and "wikis" later on. >>>> When user clicks the "wikis", the navigation tree will continue to >>>> expand to show all the sub-wiki names. >>>> >>>> It took me a while to figure out the configuration of tree content >>>> provider, tree viewer and label provider, which is a little different >>>> with what I did in Eclipse SWT development. As this has been sorted out, >>>> I would pick up the pace. >>>> >>>> Best regards >>>> Jun Han >>>> >>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> the REST api also takes into account Wikis, so you should take into >>>>>> account this into the plugin. >>>>> Also, I think that we need to display the other resources (like we do >>>>> now), but maybe we should improve that too. >>>>> >>>>> I`d suggest that we group objects by class name, something like: >>>>> >>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>> -- xwiki (main/sub wiki name) >>>>> ---- Main >>>>> ------ WebHome >>>>> -------- XWiki.XWikiComments >>>>> ---------- 0 >>>>> ---------- 1 >>>>> ---------- 2 >>>>> -------- XWiki.MyClass >>>>> ---------- 0 >>>>> ---------- 1 >>>>> etc. >>>>> >>>>> 0, 1, 2 above are object numbers, but, in the future, they might change >>>>> to some other IDs. >>>>> >>>>> The advantage of such an ordering is that, highly used pages (that have >>>>> lots of comments, or lots of objects of specific classes) will allow >>>>> easier management of the objects. >>>>> >>>>> If a list of numbers looks too blank, you could have them print the >>>>> value of the first property it their class, just like XWiki`s object >>>>> editor does and you`d have something like: >>>>> >>>>> -------- XWiki.XWikiComments >>>>> ---------- 0 : Administrator ('author' property value) >>>>> ---------- 1 : Guest >>>>> ---------- 2 : Administrator >>>>> -------- XWiki.MyClass >>>>> ---------- 0 : etc. >>>>> ---------- 1 : etc. >>>>> etc. >>>>> >>>>> I don`t know what's the status of Attachments (I don remember if we >>>>> display them or not), but we should have them as an 'implicit' first >>>>> class like: >>>>> >>>>> ------ WebHome >>>>> -------- Attachments >>>>> ---------- dog.png >>>>> ---------- spreadsheet.xls >>>>> -------- XWiki.XWikiComments >>>>> ---------- 0 : Administrator ('author' property value) >>>>> ---------- 1 : Guest >>>>> ---------- 2 : Administrator >>>>> -------- XWiki.MyClass >>>>> ---------- 0 : etc. >>>>> ---------- 1 : etc. >>>>> etc. >>>>> >>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>> again the API specs. >>>>> >>>>> You can get creative with the details on how to display/handle the new >>>>> stuff. :) >>>>> >>>>> Cheers, >>>>> Eduard >>>>>> -Fabio >>>>>> >>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>>>> Hi Fabio, >>>>>>> >>>>>>> I have finished replacing xmlrpc implementation of login functionality >>>>>>> by sending http GET request to entry point >>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>> >>>>>>> A status code of 200 will be regarded as successful while 401 means >>>>>>> login fails. >>>>>>> >>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>> org.xwiki.eclipse.core plugins. >>>>>>> >>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>>>> accordingly. >>>>>>> >>>>>>> One question is what resources are to be included in navigation panel, >>>>>>> besides xwiki -> space -> pages? and how to display them? >>>>>>> Best regards >>>>>>> >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> login/logout can be implemented in order to store on the client side >>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>>>> (like the cookie sent after a login is made using the web form) so >>>>>>>> that subsequent requests are performed on the behalf of a previously >>>>>>>> authenticated user. >>>>>>>> >>>>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>> >>>>>>>> -Fabio >>>>>>>> >>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>>>> Dear all, >>>>>>>>> >>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>> >>>>>>>>> One question is about how to implement login and logout functionality >>>>>>>>> via REST API. >>>>>>>>> From REST API document, users can be authenticated via something like: >>>>>>>>> 1. XWiki session >>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>> >>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Jun Han
Hi Vincent, Thanks a lot for your suggestion. IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5). I agree that technical details should not be exposed to end user. The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used. However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this. Best regards Jun Han On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
Hi Eduard,
Thanks a lot for prompt instruction.
I forgot to sync the screenshot to the server. Now it is the correct one.
Regarding the pluggable solution for both xml-rpc and rest, I will try to devise a common storage API for both of them.
For example, public Object getPage(String pageId) public List<Object> getPages(String spaceKey)
They will return 1. xmlrpc.model.PageSummary if connecting via xmlrpc or 2. rest.jaxb.model.Page if connecting via rest.
If this is the way to go, I will look more into how to implement this. Adapter pattern may be used.
Best regards
Jun Han
On 06/10/2011 12:08 PM, Eduard Moraru wrote: > Hi Jun, > > On 06/10/2011 05:26 PM, Jun Han wrote: >> Hi, Eduard and Fabio, >> >> I finished part of the navigation panel, which shows the connection, >> wiki, space. >> Please see the screenshot at >> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png > I think you pasted the wrong screenshot. We`ve already seen this one and > I think it's from an early stage of development. >> Adding pages under space is straightforward too, however, it requires >> re-factor a lot of source code, which spreads in the plugin of >> xwiki.eclipse.ui and xwiki.eclipse.core. >> >> I will continue work on displaying more XWiki resources after I finish >> re-factoring the properties editor, action provider (context menu), and >> other dialog windows related to connection, wiki, space. > It should not take that much of a refactoring on the UI part, since the > heavy lifting is done in the core. > > What I actually wanted to tell you is that you should take the > refactoring in a modular direction and consider your work as a > contribution and alternative for the existing system and not only as a > replacement. I you can`t do it as a contribution, consider adding a > mechanism that allows you to do so (see our first discussions on > integrating the rest back-end). Keep the abstraction layer (interfaces, > model, etc) as the main think the ui and even core components > communicate with and keep the implementation of that abstraction layer > pluggable (xml-rpc, rest, etc). The UI must also be aware of this and > act accordingly. > > We don`t want to do the same replacement work if, for whatever reason, > we want to switch to a different back-end in the future. So keep that in > mind at all time during GSoC. > > Besides that, keep up the good work ;) > > Thanks, > Eduard >> Best regards >> Jun Han >> >> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> I am not sure that syntaxes should appear as a child of connection. I >>>> would show this information in the property panel of the connection. >>> I think that you should make the "wikis" implicit as well and leave only >>> the Connection Name as top root, just like in my previous proposal: >>> >>> Connection01 >>> - wiki1 >>> -- spaceA >>> --- pageX >>> - wiki2 >>> - etc. >>> >>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>> should be displayed in the properties page of a connection. >>> >>> Also, you need to take care when the user enters the user name and >>> password and consider the wiki for which it applies. User Admin on the >>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>> (subwiki1:XWiki.Admin). >>> I believe that, if you don`t enter the absolute user name >>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>> will be resolved to the wiki of the resource you are trying to access. >>> You should, at least internally, always use absolute user names. >>> >>> Thanks, >>> Eduard >>>> Thanks, >>>> Fabio >>>> >>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> wrote: >>>>> Hi Eduard and Fabio, >>>>> >>>>> Thanks a lot for your suggestions. >>>>> >>>>> I managed to create a top-level tree expansion when user requests the >>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>> >>>>> A screenshot is available at: >>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>> >>>>> Now the labels display the whole<href> attribute, I plan to "syntaxes" >>>>> and "wikis" later on. >>>>> When user clicks the "wikis", the navigation tree will continue to >>>>> expand to show all the sub-wiki names. >>>>> >>>>> It took me a while to figure out the configuration of tree content >>>>> provider, tree viewer and label provider, which is a little different >>>>> with what I did in Eclipse SWT development. As this has been sorted out, >>>>> I would pick up the pace. >>>>> >>>>> Best regards >>>>> Jun Han >>>>> >>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>> account this into the plugin. >>>>>> Also, I think that we need to display the other resources (like we do >>>>>> now), but maybe we should improve that too. >>>>>> >>>>>> I`d suggest that we group objects by class name, something like: >>>>>> >>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>> -- xwiki (main/sub wiki name) >>>>>> ---- Main >>>>>> ------ WebHome >>>>>> -------- XWiki.XWikiComments >>>>>> ---------- 0 >>>>>> ---------- 1 >>>>>> ---------- 2 >>>>>> -------- XWiki.MyClass >>>>>> ---------- 0 >>>>>> ---------- 1 >>>>>> etc. >>>>>> >>>>>> 0, 1, 2 above are object numbers, but, in the future, they might change >>>>>> to some other IDs. >>>>>> >>>>>> The advantage of such an ordering is that, highly used pages (that have >>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>> easier management of the objects. >>>>>> >>>>>> If a list of numbers looks too blank, you could have them print the >>>>>> value of the first property it their class, just like XWiki`s object >>>>>> editor does and you`d have something like: >>>>>> >>>>>> -------- XWiki.XWikiComments >>>>>> ---------- 0 : Administrator ('author' property value) >>>>>> ---------- 1 : Guest >>>>>> ---------- 2 : Administrator >>>>>> -------- XWiki.MyClass >>>>>> ---------- 0 : etc. >>>>>> ---------- 1 : etc. >>>>>> etc. >>>>>> >>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>> display them or not), but we should have them as an 'implicit' first >>>>>> class like: >>>>>> >>>>>> ------ WebHome >>>>>> -------- Attachments >>>>>> ---------- dog.png >>>>>> ---------- spreadsheet.xls >>>>>> -------- XWiki.XWikiComments >>>>>> ---------- 0 : Administrator ('author' property value) >>>>>> ---------- 1 : Guest >>>>>> ---------- 2 : Administrator >>>>>> -------- XWiki.MyClass >>>>>> ---------- 0 : etc. >>>>>> ---------- 1 : etc. >>>>>> etc. >>>>>> >>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>> again the API specs. >>>>>> >>>>>> You can get creative with the details on how to display/handle the new >>>>>> stuff. :) >>>>>> >>>>>> Cheers, >>>>>> Eduard >>>>>>> -Fabio >>>>>>> >>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> wrote: >>>>>>>> Hi Fabio, >>>>>>>> >>>>>>>> I have finished replacing xmlrpc implementation of login functionality >>>>>>>> by sending http GET request to entry point >>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>> >>>>>>>> A status code of 200 will be regarded as successful while 401 means >>>>>>>> login fails. >>>>>>>> >>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>> >>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc code >>>>>>>> accordingly. >>>>>>>> >>>>>>>> One question is what resources are to be included in navigation panel, >>>>>>>> besides xwiki -> space -> pages? and how to display them? >>>>>>>> Best regards >>>>>>>> >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> login/logout can be implemented in order to store on the client side >>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>> Currently there is no way in the REST-api to get a "session token" >>>>>>>>> (like the cookie sent after a login is made using the web form) so >>>>>>>>> that subsequent requests are performed on the behalf of a previously >>>>>>>>> authenticated user. >>>>>>>>> >>>>>>>>> So what is usually done is to send basic-auth credentials with each request. >>>>>>>>> You can start with this. Next you might try to retrieve the cookie by >>>>>>>>> faking a standard login and using that cookie in subsequent requests. >>>>>>>>> The ideal setting would be to implement server side some OAuth-like >>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>> >>>>>>>>> -Fabio >>>>>>>>> >>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> wrote: >>>>>>>>>> Dear all, >>>>>>>>>> >>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>> >>>>>>>>>> One question is about how to implement login and logout functionality >>>>>>>>>> via REST API. >>>>>>>>>> From REST API document, users can be authenticated via something like: >>>>>>>>>> 1. XWiki session >>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>> >>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the HTTP >>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing the response. >>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, thanks, for the update. I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use. You should progress on the REST aspects asap though. Thanks, Fabio On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
> Hi Eduard, > > Thanks a lot for prompt instruction. > > I forgot to sync the screenshot to the server. Now it is the correct one. > > Regarding the pluggable solution for both xml-rpc and rest, I will try > to devise a common storage API for both of them. > > For example, > public Object getPage(String pageId) > public List<Object> getPages(String spaceKey) > > They will return > 1. xmlrpc.model.PageSummary if connecting via xmlrpc or > 2. rest.jaxb.model.Page if connecting via rest. > > If this is the way to go, I will look more into how to implement this. > Adapter pattern may be used. > > Best regards > > Jun Han > > On 06/10/2011 12:08 PM, Eduard Moraru wrote: >> Hi Jun, >> >> On 06/10/2011 05:26 PM, Jun Han wrote: >>> Hi, Eduard and Fabio, >>> >>> I finished part of the navigation panel, which shows the connection, >>> wiki, space. >>> Please see the screenshot at >>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >> I think you pasted the wrong screenshot. We`ve already seen this one and >> I think it's from an early stage of development. >>> Adding pages under space is straightforward too, however, it requires >>> re-factor a lot of source code, which spreads in the plugin of >>> xwiki.eclipse.ui and xwiki.eclipse.core. >>> >>> I will continue work on displaying more XWiki resources after I finish >>> re-factoring the properties editor, action provider (context menu), and >>> other dialog windows related to connection, wiki, space. >> It should not take that much of a refactoring on the UI part, since the >> heavy lifting is done in the core. >> >> What I actually wanted to tell you is that you should take the >> refactoring in a modular direction and consider your work as a >> contribution and alternative for the existing system and not only as a >> replacement. I you can`t do it as a contribution, consider adding a >> mechanism that allows you to do so (see our first discussions on >> integrating the rest back-end). Keep the abstraction layer (interfaces, >> model, etc) as the main think the ui and even core components >> communicate with and keep the implementation of that abstraction layer >> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >> act accordingly. >> >> We don`t want to do the same replacement work if, for whatever reason, >> we want to switch to a different back-end in the future. So keep that in >> mind at all time during GSoC. >> >> Besides that, keep up the good work ;) >> >> Thanks, >> Eduard >>> Best regards >>> Jun Han >>> >>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>> Hi Jun, >>>>> >>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>> would show this information in the property panel of the connection. >>>> I think that you should make the "wikis" implicit as well and leave > only >>>> the Connection Name as top root, just like in my previous proposal: >>>> >>>> Connection01 >>>> - wiki1 >>>> -- spaceA >>>> --- pageX >>>> - wiki2 >>>> - etc. >>>> >>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>> should be displayed in the properties page of a connection. >>>> >>>> Also, you need to take care when the user enters the user name and >>>> password and consider the wiki for which it applies. User Admin on the >>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>> (subwiki1:XWiki.Admin). >>>> I believe that, if you don`t enter the absolute user name >>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>> will be resolved to the wiki of the resource you are trying to access. >>>> You should, at least internally, always use absolute user names. >>>> >>>> Thanks, >>>> Eduard >>>>> Thanks, >>>>> Fabio >>>>> >>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> > wrote: >>>>>> Hi Eduard and Fabio, >>>>>> >>>>>> Thanks a lot for your suggestions. >>>>>> >>>>>> I managed to create a top-level tree expansion when user requests the >>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>> >>>>>> A screenshot is available at: >>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> >>>>>> Now the labels display the whole<href> attribute, I plan to > "syntaxes" >>>>>> and "wikis" later on. >>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>> expand to show all the sub-wiki names. >>>>>> >>>>>> It took me a while to figure out the configuration of tree content >>>>>> provider, tree viewer and label provider, which is a little different >>>>>> with what I did in Eclipse SWT development. As this has been sorted > out, >>>>>> I would pick up the pace. >>>>>> >>>>>> Best regards >>>>>> Jun Han >>>>>> >>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>> account this into the plugin. >>>>>>> Also, I think that we need to display the other resources (like we > do >>>>>>> now), but maybe we should improve that too. >>>>>>> >>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>> >>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>> -- xwiki (main/sub wiki name) >>>>>>> ---- Main >>>>>>> ------ WebHome >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 >>>>>>> ---------- 1 >>>>>>> ---------- 2 >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 >>>>>>> ---------- 1 >>>>>>> etc. >>>>>>> >>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might > change >>>>>>> to some other IDs. >>>>>>> >>>>>>> The advantage of such an ordering is that, highly used pages (that > have >>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>> easier management of the objects. >>>>>>> >>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>> editor does and you`d have something like: >>>>>>> >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>> ---------- 1 : Guest >>>>>>> ---------- 2 : Administrator >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 : etc. >>>>>>> ---------- 1 : etc. >>>>>>> etc. >>>>>>> >>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>> class like: >>>>>>> >>>>>>> ------ WebHome >>>>>>> -------- Attachments >>>>>>> ---------- dog.png >>>>>>> ---------- spreadsheet.xls >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>> ---------- 1 : Guest >>>>>>> ---------- 2 : Administrator >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 : etc. >>>>>>> ---------- 1 : etc. >>>>>>> etc. >>>>>>> >>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>> again the API specs. >>>>>>> >>>>>>> You can get creative with the details on how to display/handle the > new >>>>>>> stuff. :) >>>>>>> >>>>>>> Cheers, >>>>>>> Eduard >>>>>>>> -Fabio >>>>>>>> >>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> > wrote: >>>>>>>>> Hi Fabio, >>>>>>>>> >>>>>>>>> I have finished replacing xmlrpc implementation of login > functionality >>>>>>>>> by sending http GET request to entry point >>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>> >>>>>>>>> A status code of 200 will be regarded as successful while 401 > means >>>>>>>>> login fails. >>>>>>>>> >>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>> >>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc > code >>>>>>>>> accordingly. >>>>>>>>> >>>>>>>>> One question is what resources are to be included in navigation > panel, >>>>>>>>> besides xwiki -> space -> pages? and how to display > them? >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> login/logout can be implemented in order to store on the client > side >>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>> Currently there is no way in the REST-api to get a "session > token" >>>>>>>>>> (like the cookie sent after a login is made using the web form) > so >>>>>>>>>> that subsequent requests are performed on the behalf of a > previously >>>>>>>>>> authenticated user. >>>>>>>>>> >>>>>>>>>> So what is usually done is to send basic-auth credentials with > each request. >>>>>>>>>> You can start with this. Next you might try to retrieve the > cookie by >>>>>>>>>> faking a standard login and using that cookie in subsequent > requests. >>>>>>>>>> The ideal setting would be to implement server side some > OAuth-like >>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>> >>>>>>>>>> -Fabio >>>>>>>>>> >>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> > wrote: >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>> >>>>>>>>>>> One question is about how to implement login and logout > functionality >>>>>>>>>>> via REST API. >>>>>>>>>>> From REST API document, users can be authenticated via > something like: >>>>>>>>>>> 1. XWiki session >>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>> >>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the > HTTP >>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing > the response. >>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Fabio/Jun, On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote:
Hi Jun,
thanks, for the update.
I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use.
We've been supporting REST for a very long time now. My opinion is to drop XMLRPC support altogether in the next release of XEclipse. Thanks -Vincent
You should progress on the REST aspects asap though.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote: > Hi Jun, > > Instead of returning Object, you should return > org.xwiki.eclipse.core.model.Page or Object, etc. > > So the storage abstraction needs to include and abstract model as well in > order to be usable. This means that the implementation also comes with a > model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, > rest.jaxb.model.Page for rest back-end, etc.... all of them implementing > org.xwiki.eclipse.core.model.Page) > > Cheers, > Eduard > > On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: > >> Hi Eduard, >> >> Thanks a lot for prompt instruction. >> >> I forgot to sync the screenshot to the server. Now it is the correct one. >> >> Regarding the pluggable solution for both xml-rpc and rest, I will try >> to devise a common storage API for both of them. >> >> For example, >> public Object getPage(String pageId) >> public List<Object> getPages(String spaceKey) >> >> They will return >> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >> 2. rest.jaxb.model.Page if connecting via rest. >> >> If this is the way to go, I will look more into how to implement this. >> Adapter pattern may be used. >> >> Best regards >> >> Jun Han >> >> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>> Hi, Eduard and Fabio, >>>> >>>> I finished part of the navigation panel, which shows the connection, >>>> wiki, space. >>>> Please see the screenshot at >>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>> I think you pasted the wrong screenshot. We`ve already seen this one and >>> I think it's from an early stage of development. >>>> Adding pages under space is straightforward too, however, it requires >>>> re-factor a lot of source code, which spreads in the plugin of >>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>> >>>> I will continue work on displaying more XWiki resources after I finish >>>> re-factoring the properties editor, action provider (context menu), and >>>> other dialog windows related to connection, wiki, space. >>> It should not take that much of a refactoring on the UI part, since the >>> heavy lifting is done in the core. >>> >>> What I actually wanted to tell you is that you should take the >>> refactoring in a modular direction and consider your work as a >>> contribution and alternative for the existing system and not only as a >>> replacement. I you can`t do it as a contribution, consider adding a >>> mechanism that allows you to do so (see our first discussions on >>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>> model, etc) as the main think the ui and even core components >>> communicate with and keep the implementation of that abstraction layer >>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>> act accordingly. >>> >>> We don`t want to do the same replacement work if, for whatever reason, >>> we want to switch to a different back-end in the future. So keep that in >>> mind at all time during GSoC. >>> >>> Besides that, keep up the good work ;) >>> >>> Thanks, >>> Eduard >>>> Best regards >>>> Jun Han >>>> >>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>> would show this information in the property panel of the connection. >>>>> I think that you should make the "wikis" implicit as well and leave >> only >>>>> the Connection Name as top root, just like in my previous proposal: >>>>> >>>>> Connection01 >>>>> - wiki1 >>>>> -- spaceA >>>>> --- pageX >>>>> - wiki2 >>>>> - etc. >>>>> >>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>> should be displayed in the properties page of a connection. >>>>> >>>>> Also, you need to take care when the user enters the user name and >>>>> password and consider the wiki for which it applies. User Admin on the >>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>> (subwiki1:XWiki.Admin). >>>>> I believe that, if you don`t enter the absolute user name >>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>> will be resolved to the wiki of the resource you are trying to access. >>>>> You should, at least internally, always use absolute user names. >>>>> >>>>> Thanks, >>>>> Eduard >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >> wrote: >>>>>>> Hi Eduard and Fabio, >>>>>>> >>>>>>> Thanks a lot for your suggestions. >>>>>>> >>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>> >>>>>>> A screenshot is available at: >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>> >>>>>>> Now the labels display the whole<href> attribute, I plan to >> "syntaxes" >>>>>>> and "wikis" later on. >>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>> expand to show all the sub-wiki names. >>>>>>> >>>>>>> It took me a while to figure out the configuration of tree content >>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>> with what I did in Eclipse SWT development. As this has been sorted >> out, >>>>>>> I would pick up the pace. >>>>>>> >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>> account this into the plugin. >>>>>>>> Also, I think that we need to display the other resources (like we >> do >>>>>>>> now), but maybe we should improve that too. >>>>>>>> >>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>> >>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>> ---- Main >>>>>>>> ------ WebHome >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 >>>>>>>> ---------- 1 >>>>>>>> ---------- 2 >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 >>>>>>>> ---------- 1 >>>>>>>> etc. >>>>>>>> >>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >> change >>>>>>>> to some other IDs. >>>>>>>> >>>>>>>> The advantage of such an ordering is that, highly used pages (that >> have >>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>> easier management of the objects. >>>>>>>> >>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>> editor does and you`d have something like: >>>>>>>> >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>> ---------- 1 : Guest >>>>>>>> ---------- 2 : Administrator >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 : etc. >>>>>>>> ---------- 1 : etc. >>>>>>>> etc. >>>>>>>> >>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>> class like: >>>>>>>> >>>>>>>> ------ WebHome >>>>>>>> -------- Attachments >>>>>>>> ---------- dog.png >>>>>>>> ---------- spreadsheet.xls >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>> ---------- 1 : Guest >>>>>>>> ---------- 2 : Administrator >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 : etc. >>>>>>>> ---------- 1 : etc. >>>>>>>> etc. >>>>>>>> >>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>> again the API specs. >>>>>>>> >>>>>>>> You can get creative with the details on how to display/handle the >> new >>>>>>>> stuff. :) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eduard >>>>>>>>> -Fabio >>>>>>>>> >>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >> wrote: >>>>>>>>>> Hi Fabio, >>>>>>>>>> >>>>>>>>>> I have finished replacing xmlrpc implementation of login >> functionality >>>>>>>>>> by sending http GET request to entry point >>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>> >>>>>>>>>> A status code of 200 will be regarded as successful while 401 >> means >>>>>>>>>> login fails. >>>>>>>>>> >>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>> >>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >> code >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> One question is what resources are to be included in navigation >> panel, >>>>>>>>>> besides xwiki -> space -> pages? and how to display >> them? >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> login/logout can be implemented in order to store on the client >> side >>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>> Currently there is no way in the REST-api to get a "session >> token" >>>>>>>>>>> (like the cookie sent after a login is made using the web form) >> so >>>>>>>>>>> that subsequent requests are performed on the behalf of a >> previously >>>>>>>>>>> authenticated user. >>>>>>>>>>> >>>>>>>>>>> So what is usually done is to send basic-auth credentials with >> each request. >>>>>>>>>>> You can start with this. Next you might try to retrieve the >> cookie by >>>>>>>>>>> faking a standard login and using that cookie in subsequent >> requests. >>>>>>>>>>> The ideal setting would be to implement server side some >> OAuth-like >>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>> >>>>>>>>>>> -Fabio >>>>>>>>>>> >>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >> wrote: >>>>>>>>>>>> Dear all, >>>>>>>>>>>> >>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>> >>>>>>>>>>>> One question is about how to implement login and logout >> functionality >>>>>>>>>>>> via REST API. >>>>>>>>>>>> From REST API document, users can be authenticated via >> something like: >>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>> >>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >> HTTP >>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >> the response. >>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Jun Han
On Mon, Jun 20, 2011 at 10:48, Vincent Massol <[email protected]> wrote:
Hi Fabio/Jun,
On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote:
Hi Jun,
thanks, for the update.
I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use.
We've been supporting REST for a very long time now. My opinion is to drop XMLRPC support altogether in the next release of XEclipse.
Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account.
Thanks -Vincent
You should progress on the REST aspects asap though.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: > Dear all, > > After I looked into the current implementation of XEclipse and tried > several attempts, one plan, whose goal is to provide an abstract > communication layer between XEclipse and server, might be feasible. > A rough system diagram showing the relationships of plugins of XWiki > Eclipse is available at: > http://dl.dropbox.com/u/3466762/xwiki/architecture.png > > In order to remove dependency of particular back-end implementation > (xmlrpc or rest), > an abstract layer, which includes two plugins (model and storage) will > be created. > 1. model plugin contains the current package of xwiki.eclipse.core.model > 2. storage plugin contains xwiki.eclipse.core.storage including two > abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. > > In this way, all the core implementation and UI components (dialogs, > properties dialog, adapters) in ui plugin will now depend on the model > and storage plugins rather than the xmlrpc implementation. > > Instead of only providing the required jar files, xmlrpc and rest > plugins will also do the following: > 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in > storage plugin > 2. extend the model classes in model plugin > > In this way, all the abstract classes in model and storage plugins will > be initialized in the run time and perform the specified functions. > > If my understanding is correct, I will begin re-factoring work. > > Best regards > > Jun Han > > On 6/11/2011 10:32 AM, Eduard Moraru wrote: >> Hi Jun, >> >> Instead of returning Object, you should return >> org.xwiki.eclipse.core.model.Page or Object, etc. >> >> So the storage abstraction needs to include and abstract model as well in >> order to be usable. This means that the implementation also comes with a >> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >> org.xwiki.eclipse.core.model.Page) >> >> Cheers, >> Eduard >> >> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >> >>> Hi Eduard, >>> >>> Thanks a lot for prompt instruction. >>> >>> I forgot to sync the screenshot to the server. Now it is the correct one. >>> >>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>> to devise a common storage API for both of them. >>> >>> For example, >>> public Object getPage(String pageId) >>> public List<Object> getPages(String spaceKey) >>> >>> They will return >>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>> 2. rest.jaxb.model.Page if connecting via rest. >>> >>> If this is the way to go, I will look more into how to implement this. >>> Adapter pattern may be used. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>> Hi, Eduard and Fabio, >>>>> >>>>> I finished part of the navigation panel, which shows the connection, >>>>> wiki, space. >>>>> Please see the screenshot at >>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>> I think it's from an early stage of development. >>>>> Adding pages under space is straightforward too, however, it requires >>>>> re-factor a lot of source code, which spreads in the plugin of >>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>> >>>>> I will continue work on displaying more XWiki resources after I finish >>>>> re-factoring the properties editor, action provider (context menu), and >>>>> other dialog windows related to connection, wiki, space. >>>> It should not take that much of a refactoring on the UI part, since the >>>> heavy lifting is done in the core. >>>> >>>> What I actually wanted to tell you is that you should take the >>>> refactoring in a modular direction and consider your work as a >>>> contribution and alternative for the existing system and not only as a >>>> replacement. I you can`t do it as a contribution, consider adding a >>>> mechanism that allows you to do so (see our first discussions on >>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>> model, etc) as the main think the ui and even core components >>>> communicate with and keep the implementation of that abstraction layer >>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>> act accordingly. >>>> >>>> We don`t want to do the same replacement work if, for whatever reason, >>>> we want to switch to a different back-end in the future. So keep that in >>>> mind at all time during GSoC. >>>> >>>> Besides that, keep up the good work ;) >>>> >>>> Thanks, >>>> Eduard >>>>> Best regards >>>>> Jun Han >>>>> >>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>> would show this information in the property panel of the connection. >>>>>> I think that you should make the "wikis" implicit as well and leave >>> only >>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>> >>>>>> Connection01 >>>>>> - wiki1 >>>>>> -- spaceA >>>>>> --- pageX >>>>>> - wiki2 >>>>>> - etc. >>>>>> >>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>> should be displayed in the properties page of a connection. >>>>>> >>>>>> Also, you need to take care when the user enters the user name and >>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>> (subwiki1:XWiki.Admin). >>>>>> I believe that, if you don`t enter the absolute user name >>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>> You should, at least internally, always use absolute user names. >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Thanks, >>>>>>> Fabio >>>>>>> >>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >>> wrote: >>>>>>>> Hi Eduard and Fabio, >>>>>>>> >>>>>>>> Thanks a lot for your suggestions. >>>>>>>> >>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>> >>>>>>>> A screenshot is available at: >>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>> >>>>>>>> Now the labels display the whole<href> attribute, I plan to >>> "syntaxes" >>>>>>>> and "wikis" later on. >>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>> expand to show all the sub-wiki names. >>>>>>>> >>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>> out, >>>>>>>> I would pick up the pace. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>> account this into the plugin. >>>>>>>>> Also, I think that we need to display the other resources (like we >>> do >>>>>>>>> now), but maybe we should improve that too. >>>>>>>>> >>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>> >>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>> ---- Main >>>>>>>>> ------ WebHome >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 >>>>>>>>> ---------- 1 >>>>>>>>> ---------- 2 >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 >>>>>>>>> ---------- 1 >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>> change >>>>>>>>> to some other IDs. >>>>>>>>> >>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>> have >>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>> easier management of the objects. >>>>>>>>> >>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>> editor does and you`d have something like: >>>>>>>>> >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>> ---------- 1 : Guest >>>>>>>>> ---------- 2 : Administrator >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 : etc. >>>>>>>>> ---------- 1 : etc. >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>> class like: >>>>>>>>> >>>>>>>>> ------ WebHome >>>>>>>>> -------- Attachments >>>>>>>>> ---------- dog.png >>>>>>>>> ---------- spreadsheet.xls >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>> ---------- 1 : Guest >>>>>>>>> ---------- 2 : Administrator >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 : etc. >>>>>>>>> ---------- 1 : etc. >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>> again the API specs. >>>>>>>>> >>>>>>>>> You can get creative with the details on how to display/handle the >>> new >>>>>>>>> stuff. :) >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Eduard >>>>>>>>>> -Fabio >>>>>>>>>> >>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >>> wrote: >>>>>>>>>>> Hi Fabio, >>>>>>>>>>> >>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>> functionality >>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>> >>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>> means >>>>>>>>>>> login fails. >>>>>>>>>>> >>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>> >>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>> code >>>>>>>>>>> accordingly. >>>>>>>>>>> >>>>>>>>>>> One question is what resources are to be included in navigation >>> panel, >>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>> them? >>>>>>>>>>> Best regards >>>>>>>>>>> >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> login/logout can be implemented in order to store on the client >>> side >>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>> token" >>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>> so >>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>> previously >>>>>>>>>>>> authenticated user. >>>>>>>>>>>> >>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>> each request. >>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>> cookie by >>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>> requests. >>>>>>>>>>>> The ideal setting would be to implement server side some >>> OAuth-like >>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>> >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >>> wrote: >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>> >>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is about how to implement login and logout >>> functionality >>>>>>>>>>>>> via REST API. >>>>>>>>>>>>> From REST API document, users can be authenticated via >>> something like: >>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>> >>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>> HTTP >>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>> the response. >>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
This leads to a general question: do we want to continue supporting XMLRPC in XWiki, in the platform (now that we have good REST support) or should we drop it and move it as a contrib/retired module? (once we've migrated all our modules to use REST of course. I can think ok xeclipse and some functional tests). Thanks -Vincent On Jun 20, 2011, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Jun 20, 2011 at 10:48, Vincent Massol <[email protected]> wrote:
Hi Fabio/Jun,
On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote:
Hi Jun,
thanks, for the update.
I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use.
We've been supporting REST for a very long time now. My opinion is to drop XMLRPC support altogether in the next release of XEclipse.
Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account.
Thanks -Vincent
You should progress on the REST aspects asap though.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: > Hi Jun, > > could you post a status about your work? > Your commits stream > (https://github.com/junhan/xwiki-eclipse/commits/master) is not very > informative (are you holding commits locally? If so you should push > more frequently!) > > Midterm is approaching so we need to make things advance a little bit faster. > > Thanks, > Fabio > > > > On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >> Dear all, >> >> After I looked into the current implementation of XEclipse and tried >> several attempts, one plan, whose goal is to provide an abstract >> communication layer between XEclipse and server, might be feasible. >> A rough system diagram showing the relationships of plugins of XWiki >> Eclipse is available at: >> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >> >> In order to remove dependency of particular back-end implementation >> (xmlrpc or rest), >> an abstract layer, which includes two plugins (model and storage) will >> be created. >> 1. model plugin contains the current package of xwiki.eclipse.core.model >> 2. storage plugin contains xwiki.eclipse.core.storage including two >> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >> >> In this way, all the core implementation and UI components (dialogs, >> properties dialog, adapters) in ui plugin will now depend on the model >> and storage plugins rather than the xmlrpc implementation. >> >> Instead of only providing the required jar files, xmlrpc and rest >> plugins will also do the following: >> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >> storage plugin >> 2. extend the model classes in model plugin >> >> In this way, all the abstract classes in model and storage plugins will >> be initialized in the run time and perform the specified functions. >> >> If my understanding is correct, I will begin re-factoring work. >> >> Best regards >> >> Jun Han >> >> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> Instead of returning Object, you should return >>> org.xwiki.eclipse.core.model.Page or Object, etc. >>> >>> So the storage abstraction needs to include and abstract model as well in >>> order to be usable. This means that the implementation also comes with a >>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>> org.xwiki.eclipse.core.model.Page) >>> >>> Cheers, >>> Eduard >>> >>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>> >>>> Hi Eduard, >>>> >>>> Thanks a lot for prompt instruction. >>>> >>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>> >>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>> to devise a common storage API for both of them. >>>> >>>> For example, >>>> public Object getPage(String pageId) >>>> public List<Object> getPages(String spaceKey) >>>> >>>> They will return >>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>> 2. rest.jaxb.model.Page if connecting via rest. >>>> >>>> If this is the way to go, I will look more into how to implement this. >>>> Adapter pattern may be used. >>>> >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>> Hi, Eduard and Fabio, >>>>>> >>>>>> I finished part of the navigation panel, which shows the connection, >>>>>> wiki, space. >>>>>> Please see the screenshot at >>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>> I think it's from an early stage of development. >>>>>> Adding pages under space is straightforward too, however, it requires >>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>> >>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>> other dialog windows related to connection, wiki, space. >>>>> It should not take that much of a refactoring on the UI part, since the >>>>> heavy lifting is done in the core. >>>>> >>>>> What I actually wanted to tell you is that you should take the >>>>> refactoring in a modular direction and consider your work as a >>>>> contribution and alternative for the existing system and not only as a >>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>> mechanism that allows you to do so (see our first discussions on >>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>> model, etc) as the main think the ui and even core components >>>>> communicate with and keep the implementation of that abstraction layer >>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>> act accordingly. >>>>> >>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>> we want to switch to a different back-end in the future. So keep that in >>>>> mind at all time during GSoC. >>>>> >>>>> Besides that, keep up the good work ;) >>>>> >>>>> Thanks, >>>>> Eduard >>>>>> Best regards >>>>>> Jun Han >>>>>> >>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>> would show this information in the property panel of the connection. >>>>>>> I think that you should make the "wikis" implicit as well and leave >>>> only >>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>> >>>>>>> Connection01 >>>>>>> - wiki1 >>>>>>> -- spaceA >>>>>>> --- pageX >>>>>>> - wiki2 >>>>>>> - etc. >>>>>>> >>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>> should be displayed in the properties page of a connection. >>>>>>> >>>>>>> Also, you need to take care when the user enters the user name and >>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>> (subwiki1:XWiki.Admin). >>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>> You should, at least internally, always use absolute user names. >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>>> Thanks, >>>>>>>> Fabio >>>>>>>> >>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >>>> wrote: >>>>>>>>> Hi Eduard and Fabio, >>>>>>>>> >>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>> >>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>> >>>>>>>>> A screenshot is available at: >>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>> >>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>> "syntaxes" >>>>>>>>> and "wikis" later on. >>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>> >>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>> out, >>>>>>>>> I would pick up the pace. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>> account this into the plugin. >>>>>>>>>> Also, I think that we need to display the other resources (like we >>>> do >>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>> >>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>> >>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>> ---- Main >>>>>>>>>> ------ WebHome >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 >>>>>>>>>> ---------- 1 >>>>>>>>>> ---------- 2 >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 >>>>>>>>>> ---------- 1 >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>> change >>>>>>>>>> to some other IDs. >>>>>>>>>> >>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>> have >>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>> easier management of the objects. >>>>>>>>>> >>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>> editor does and you`d have something like: >>>>>>>>>> >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>> ---------- 1 : Guest >>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 : etc. >>>>>>>>>> ---------- 1 : etc. >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>> class like: >>>>>>>>>> >>>>>>>>>> ------ WebHome >>>>>>>>>> -------- Attachments >>>>>>>>>> ---------- dog.png >>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>> ---------- 1 : Guest >>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 : etc. >>>>>>>>>> ---------- 1 : etc. >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>> again the API specs. >>>>>>>>>> >>>>>>>>>> You can get creative with the details on how to display/handle the >>>> new >>>>>>>>>> stuff. :) >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Eduard >>>>>>>>>>> -Fabio >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >>>> wrote: >>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>> >>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>> functionality >>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>> >>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>> means >>>>>>>>>>>> login fails. >>>>>>>>>>>> >>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>> >>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>> code >>>>>>>>>>>> accordingly. >>>>>>>>>>>> >>>>>>>>>>>> One question is what resources are to be included in navigation >>>> panel, >>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>> them? >>>>>>>>>>>> Best regards >>>>>>>>>>>> >>>>>>>>>>>> Jun Han >>>>>>>>>>>> >>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>> side >>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>> token" >>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>> so >>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>> previously >>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>> >>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>> each request. >>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>> cookie by >>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>> requests. >>>>>>>>>>>>> The ideal setting would be to implement server side some >>>> OAuth-like >>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>> >>>>>>>>>>>>> -Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >>>> wrote: >>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question is about how to implement login and logout >>>> functionality >>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>> something like: >>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>> >>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>> HTTP >>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>> the response. >>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> Jun Han
Hi, On Mon, Jun 20, 2011 at 12:05 PM, Vincent Massol <[email protected]> wrote:
This leads to a general question: do we want to continue supporting XMLRPC in XWiki, in the platform (now that we have good REST support) or should we drop it and move it as a contrib/retired module? (once we've migrated all our modules to use REST of course. I can think ok xeclipse and some functional tests).
Keep it for now. The maintenance cost is not very high. XOffice still depends on it. Note that REST does not cover the entire XML-RPC functionality yet(iirc it's missing syntax conversion, search, and a few others). Florin
Thanks -Vincent
On Jun 20, 2011, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Jun 20, 2011 at 10:48, Vincent Massol <[email protected]> wrote:
Hi Fabio/Jun,
On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote:
Hi Jun,
thanks, for the update.
I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use.
We've been supporting REST for a very long time now. My opinion is to drop XMLRPC support altogether in the next release of XEclipse.
Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account.
Thanks -Vincent
You should progress on the REST aspects asap though.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input
of
server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
> Hi Fabio, > > I have already finished re-factoring the whole xmlrpc backend. > > A new combo list is added to the "new connection" wizard to provide two > choices (xmlrpc and rest), as shown in > http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. > > When user selects "xmlrpc", the xmlrpc implementation is used. The > navigation panel can show the xwiki resources, as shown in > http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. > > I will continue working on the rest backend following the previous > discussion. > > Best regards > > Jun Han > > On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> could you post a status about your work? >> Your commits stream >> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >> informative (are you holding commits locally? If so you should push >> more frequently!) >> >> Midterm is approaching so we need to make things advance a little bit faster. >> >> Thanks, >> Fabio >> >> >> >> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> After I looked into the current implementation of XEclipse and tried >>> several attempts, one plan, whose goal is to provide an abstract >>> communication layer between XEclipse and server, might be feasible. >>> A rough system diagram showing the relationships of plugins of XWiki >>> Eclipse is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>> >>> In order to remove dependency of particular back-end implementation >>> (xmlrpc or rest), >>> an abstract layer, which includes two plugins (model and storage) will >>> be created. >>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>> >>> In this way, all the core implementation and UI components (dialogs, >>> properties dialog, adapters) in ui plugin will now depend on the model >>> and storage plugins rather than the xmlrpc implementation. >>> >>> Instead of only providing the required jar files, xmlrpc and rest >>> plugins will also do the following: >>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>> storage plugin >>> 2. extend the model classes in model plugin >>> >>> In this way, all the abstract classes in model and storage plugins will >>> be initialized in the run time and perform the specified functions. >>> >>> If my understanding is correct, I will begin re-factoring work. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Instead of returning Object, you should return >>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>> >>>> So the storage abstraction needs to include and abstract model as well in >>>> order to be usable. This means that the implementation also comes with a >>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>> org.xwiki.eclipse.core.model.Page) >>>> >>>> Cheers, >>>> Eduard >>>> >>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>> >>>>> Hi Eduard, >>>>> >>>>> Thanks a lot for prompt instruction. >>>>> >>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>> >>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>> to devise a common storage API for both of them. >>>>> >>>>> For example, >>>>> public Object getPage(String pageId) >>>>> public List<Object> getPages(String spaceKey) >>>>> >>>>> They will return >>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>> >>>>> If this is the way to go, I will look more into how to implement this. >>>>> Adapter pattern may be used. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>> Hi, Eduard and Fabio, >>>>>>> >>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>> wiki, space. >>>>>>> Please see the screenshot at >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>> I think it's from an early stage of development. >>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>> >>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>> other dialog windows related to connection, wiki, space. >>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>> heavy lifting is done in the core. >>>>>> >>>>>> What I actually wanted to tell you is that you should take the >>>>>> refactoring in a modular direction and consider your work as a >>>>>> contribution and alternative for the existing system and not only as a >>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>> mechanism that allows you to do so (see our first discussions on >>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>> model, etc) as the main think the ui and even core components >>>>>> communicate with and keep the implementation of that abstraction layer >>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>> act accordingly. >>>>>> >>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>> mind at all time during GSoC. >>>>>> >>>>>> Besides that, keep up the good work ;) >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>> would show this information in the property panel of the connection. >>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>> only >>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>> >>>>>>>> Connection01 >>>>>>>> - wiki1 >>>>>>>> -- spaceA >>>>>>>> --- pageX >>>>>>>> - wiki2 >>>>>>>> - etc. >>>>>>>> >>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>> should be displayed in the properties page of a connection. >>>>>>>> >>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>> >>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>> >>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>> >>>>>>>>>> A screenshot is available at: >>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> >>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>> "syntaxes" >>>>>>>>>> and "wikis" later on. >>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>> >>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>> out, >>>>>>>>>> I would pick up the pace. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>> account this into the plugin. >>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>> do >>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>> >>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>> >>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>> ---- Main >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> ---------- 2 >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>> change >>>>>>>>>>> to some other IDs. >>>>>>>>>>> >>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>> have >>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>> easier management of the objects. >>>>>>>>>>> >>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>> >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>> class like: >>>>>>>>>>> >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- Attachments >>>>>>>>>>> ---------- dog.png >>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>> again the API specs. >>>>>>>>>>> >>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>> new >>>>>>>>>>> stuff. :) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Eduard >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>> >>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>> functionality >>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>> >>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>> means >>>>>>>>>>>>> login fails. >>>>>>>>>>>>> >>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>> code >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>> panel, >>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>> them? >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jun Han >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>> side >>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>> token" >>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>> so >>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>> previously >>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>> each request. >>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>> cookie by >>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>> requests. >>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>> OAuth-like >>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>> functionality >>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>> something like: >>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>> HTTP >>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>> the response. >>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, +1 for hiding the back-end choice, either trough an Advanced section, or to be determined from the URI. For dropping XMLRPC from XEclipse, I`d say we should drop it as soon as XE drops it. It's no trouble to return null or a default value for a method that is not supported by XMLRPC. For dropping XMLRPC from XE/platform, +1 as long as it's viable (new services to implement in REST, XOffice refactoring, etc.) :) Jun, as far as I have scanned your commits, good job on the refactoring :) I don`t necessarily like the hardcoded (static instead of dynamic -- discoverable) types of storages, but that's not the main problem right now. Start replacing that UnsupportedOperationException for the REST storage with some code ;) Cheers, Eduard On 06/20/2011 12:30 PM, Florin Ciubotaru wrote:
Hi,
On Mon, Jun 20, 2011 at 12:05 PM, Vincent Massol<[email protected]> wrote:
This leads to a general question: do we want to continue supporting XMLRPC in XWiki, in the platform (now that we have good REST support) or should we drop it and move it as a contrib/retired module? (once we've migrated all our modules to use REST of course. I can think ok xeclipse and some functional tests). Keep it for now. The maintenance cost is not very high. XOffice still depends on it. Note that REST does not cover the entire XML-RPC functionality yet(iirc it's missing syntax conversion, search, and a few others).
Florin
Thanks -Vincent
On Jun 20, 2011, at 10:57 AM, Thomas Mortagne wrote:
On Mon, Jun 20, 2011 at 10:48, Vincent Massol<[email protected]> wrote:
Hi Fabio/Jun,
On Jun 20, 2011, at 10:44 AM, Fabio Mancinelli wrote:
Hi Jun,
thanks, for the update.
I agree with Vincent... The backend should not be an explicit choice made for each connection. REST should be the default and if you need XMLRPC (for example for connecting to a veeeery old XWiki instance) you might have an advanced button that allows you to do this or, as you suggested, the URI might suggest the backend to use. We've been supporting REST for a very long time now. My opinion is to drop XMLRPC support altogether in the next release of XEclipse. Isn't XMLRPC support used to mean Confluence support ? I really don't care about Confluence support if you ask me, just making sure we are taking everything into account.
Thanks -Vincent
You should progress on the REST aspects asap though.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote: > Hi there, > > I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? > Also why do we want to have to maintain several backends? > > IMO we should only use one and use the REST API only. > > If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. > The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. > Thanks > -Vincent > > On Jun 19, 2011, at 6:52 AM, Jun Han wrote: > >> Hi Fabio, >> >> I have already finished re-factoring the whole xmlrpc backend. >> >> A new combo list is added to the "new connection" wizard to provide two >> choices (xmlrpc and rest), as shown in >> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >> >> When user selects "xmlrpc", the xmlrpc implementation is used. The >> navigation panel can show the xwiki resources, as shown in >> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >> >> I will continue working on the rest backend following the previous >> discussion. >> >> Best regards >> >> Jun Han >> >> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> could you post a status about your work? >>> Your commits stream >>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>> informative (are you holding commits locally? If so you should push >>> more frequently!) >>> >>> Midterm is approaching so we need to make things advance a little bit faster. >>> Thanks, >>> Fabio >>> >>> >>> >>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>> Dear all, >>>> >>>> After I looked into the current implementation of XEclipse and tried >>>> several attempts, one plan, whose goal is to provide an abstract >>>> communication layer between XEclipse and server, might be feasible. >>>> A rough system diagram showing the relationships of plugins of XWiki >>>> Eclipse is available at: >>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>> >>>> In order to remove dependency of particular back-end implementation >>>> (xmlrpc or rest), >>>> an abstract layer, which includes two plugins (model and storage) will >>>> be created. >>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>> In this way, all the core implementation and UI components (dialogs, >>>> properties dialog, adapters) in ui plugin will now depend on the model >>>> and storage plugins rather than the xmlrpc implementation. >>>> >>>> Instead of only providing the required jar files, xmlrpc and rest >>>> plugins will also do the following: >>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>> storage plugin >>>> 2. extend the model classes in model plugin >>>> >>>> In this way, all the abstract classes in model and storage plugins will >>>> be initialized in the run time and perform the specified functions. >>>> If my understanding is correct, I will begin re-factoring work. >>>> >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> Instead of returning Object, you should return >>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>> >>>>> So the storage abstraction needs to include and abstract model as well in >>>>> order to be usable. This means that the implementation also comes with a >>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>> org.xwiki.eclipse.core.model.Page) >>>>> >>>>> Cheers, >>>>> Eduard >>>>> >>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>>> Hi Eduard, >>>>>> >>>>>> Thanks a lot for prompt instruction. >>>>>> >>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>> to devise a common storage API for both of them. >>>>>> >>>>>> For example, >>>>>> public Object getPage(String pageId) >>>>>> public List<Object> getPages(String spaceKey) >>>>>> >>>>>> They will return >>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>> >>>>>> If this is the way to go, I will look more into how to implement this. >>>>>> Adapter pattern may be used. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Jun Han >>>>>> >>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>> Hi, Eduard and Fabio, >>>>>>>> >>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>> wiki, space. >>>>>>>> Please see the screenshot at >>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>> I think it's from an early stage of development. >>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>> >>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>> heavy lifting is done in the core. >>>>>>> >>>>>>> What I actually wanted to tell you is that you should take the >>>>>>> refactoring in a modular direction and consider your work as a >>>>>>> contribution and alternative for the existing system and not only as a >>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>> model, etc) as the main think the ui and even core components >>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>> act accordingly. >>>>>>> >>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>> mind at all time during GSoC. >>>>>>> >>>>>>> Besides that, keep up the good work ;) >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>> only >>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>> Connection01 >>>>>>>>> - wiki1 >>>>>>>>> -- spaceA >>>>>>>>> --- pageX >>>>>>>>> - wiki2 >>>>>>>>> - etc. >>>>>>>>> >>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>> >>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>> Thanks, >>>>>>>>> Eduard >>>>>>>>>> Thanks, >>>>>>>>>> Fabio >>>>>>>>>> >>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>> >>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>> >>>>>>>>>>> A screenshot is available at: >>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>> "syntaxes" >>>>>>>>>>> and "wikis" later on. >>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>> >>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>> out, >>>>>>>>>>> I would pick up the pace. >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>> do >>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>> >>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>> ---- Main >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> ---------- 2 >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>> change >>>>>>>>>>>> to some other IDs. >>>>>>>>>>>> >>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>> have >>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>> >>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>> >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>> class like: >>>>>>>>>>>> >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- Attachments >>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>> again the API specs. >>>>>>>>>>>> >>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>> new >>>>>>>>>>>> stuff. :) >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Eduard >>>>>>>>>>>>> -Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>> functionality >>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>> means >>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>> code >>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>> panel, >>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>> them? >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>> side >>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>> token" >>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>> so >>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>> previously >>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>> each request. >>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>> cookie by >>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>> requests. >>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>> OAuth-like >>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>> functionality >>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>> something like: >>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>> HTTP >>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>> the response. >>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :)) Please take a look. Thanks, Fabio On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote:
Hi Jun,
Instead of returning Object, you should return org.xwiki.eclipse.core.model.Page or Object, etc.
So the storage abstraction needs to include and abstract model as well in order to be usable. This means that the implementation also comes with a model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, rest.jaxb.model.Page for rest back-end, etc.... all of them implementing org.xwiki.eclipse.core.model.Page)
Cheers, Eduard
On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote:
> Hi Eduard, > > Thanks a lot for prompt instruction. > > I forgot to sync the screenshot to the server. Now it is the correct one. > > Regarding the pluggable solution for both xml-rpc and rest, I will try > to devise a common storage API for both of them. > > For example, > public Object getPage(String pageId) > public List<Object> getPages(String spaceKey) > > They will return > 1. xmlrpc.model.PageSummary if connecting via xmlrpc or > 2. rest.jaxb.model.Page if connecting via rest. > > If this is the way to go, I will look more into how to implement this. > Adapter pattern may be used. > > Best regards > > Jun Han > > On 06/10/2011 12:08 PM, Eduard Moraru wrote: >> Hi Jun, >> >> On 06/10/2011 05:26 PM, Jun Han wrote: >>> Hi, Eduard and Fabio, >>> >>> I finished part of the navigation panel, which shows the connection, >>> wiki, space. >>> Please see the screenshot at >>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >> I think you pasted the wrong screenshot. We`ve already seen this one and >> I think it's from an early stage of development. >>> Adding pages under space is straightforward too, however, it requires >>> re-factor a lot of source code, which spreads in the plugin of >>> xwiki.eclipse.ui and xwiki.eclipse.core. >>> >>> I will continue work on displaying more XWiki resources after I finish >>> re-factoring the properties editor, action provider (context menu), and >>> other dialog windows related to connection, wiki, space. >> It should not take that much of a refactoring on the UI part, since the >> heavy lifting is done in the core. >> >> What I actually wanted to tell you is that you should take the >> refactoring in a modular direction and consider your work as a >> contribution and alternative for the existing system and not only as a >> replacement. I you can`t do it as a contribution, consider adding a >> mechanism that allows you to do so (see our first discussions on >> integrating the rest back-end). Keep the abstraction layer (interfaces, >> model, etc) as the main think the ui and even core components >> communicate with and keep the implementation of that abstraction layer >> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >> act accordingly. >> >> We don`t want to do the same replacement work if, for whatever reason, >> we want to switch to a different back-end in the future. So keep that in >> mind at all time during GSoC. >> >> Besides that, keep up the good work ;) >> >> Thanks, >> Eduard >>> Best regards >>> Jun Han >>> >>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>> Hi Jun, >>>>> >>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>> would show this information in the property panel of the connection. >>>> I think that you should make the "wikis" implicit as well and leave > only >>>> the Connection Name as top root, just like in my previous proposal: >>>> >>>> Connection01 >>>> - wiki1 >>>> -- spaceA >>>> --- pageX >>>> - wiki2 >>>> - etc. >>>> >>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>> should be displayed in the properties page of a connection. >>>> >>>> Also, you need to take care when the user enters the user name and >>>> password and consider the wiki for which it applies. User Admin on the >>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>> (subwiki1:XWiki.Admin). >>>> I believe that, if you don`t enter the absolute user name >>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>> will be resolved to the wiki of the resource you are trying to access. >>>> You should, at least internally, always use absolute user names. >>>> >>>> Thanks, >>>> Eduard >>>>> Thanks, >>>>> Fabio >>>>> >>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> > wrote: >>>>>> Hi Eduard and Fabio, >>>>>> >>>>>> Thanks a lot for your suggestions. >>>>>> >>>>>> I managed to create a top-level tree expansion when user requests the >>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>> >>>>>> A screenshot is available at: >>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> >>>>>> Now the labels display the whole<href> attribute, I plan to > "syntaxes" >>>>>> and "wikis" later on. >>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>> expand to show all the sub-wiki names. >>>>>> >>>>>> It took me a while to figure out the configuration of tree content >>>>>> provider, tree viewer and label provider, which is a little different >>>>>> with what I did in Eclipse SWT development. As this has been sorted > out, >>>>>> I would pick up the pace. >>>>>> >>>>>> Best regards >>>>>> Jun Han >>>>>> >>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>> account this into the plugin. >>>>>>> Also, I think that we need to display the other resources (like we > do >>>>>>> now), but maybe we should improve that too. >>>>>>> >>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>> >>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>> -- xwiki (main/sub wiki name) >>>>>>> ---- Main >>>>>>> ------ WebHome >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 >>>>>>> ---------- 1 >>>>>>> ---------- 2 >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 >>>>>>> ---------- 1 >>>>>>> etc. >>>>>>> >>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might > change >>>>>>> to some other IDs. >>>>>>> >>>>>>> The advantage of such an ordering is that, highly used pages (that > have >>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>> easier management of the objects. >>>>>>> >>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>> editor does and you`d have something like: >>>>>>> >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>> ---------- 1 : Guest >>>>>>> ---------- 2 : Administrator >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 : etc. >>>>>>> ---------- 1 : etc. >>>>>>> etc. >>>>>>> >>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>> class like: >>>>>>> >>>>>>> ------ WebHome >>>>>>> -------- Attachments >>>>>>> ---------- dog.png >>>>>>> ---------- spreadsheet.xls >>>>>>> -------- XWiki.XWikiComments >>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>> ---------- 1 : Guest >>>>>>> ---------- 2 : Administrator >>>>>>> -------- XWiki.MyClass >>>>>>> ---------- 0 : etc. >>>>>>> ---------- 1 : etc. >>>>>>> etc. >>>>>>> >>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>> again the API specs. >>>>>>> >>>>>>> You can get creative with the details on how to display/handle the > new >>>>>>> stuff. :) >>>>>>> >>>>>>> Cheers, >>>>>>> Eduard >>>>>>>> -Fabio >>>>>>>> >>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> > wrote: >>>>>>>>> Hi Fabio, >>>>>>>>> >>>>>>>>> I have finished replacing xmlrpc implementation of login > functionality >>>>>>>>> by sending http GET request to entry point >>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>> >>>>>>>>> A status code of 200 will be regarded as successful while 401 > means >>>>>>>>> login fails. >>>>>>>>> >>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>> >>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc > code >>>>>>>>> accordingly. >>>>>>>>> >>>>>>>>> One question is what resources are to be included in navigation > panel, >>>>>>>>> besides xwiki -> space -> pages? and how to display > them? >>>>>>>>> Best regards >>>>>>>>> >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> login/logout can be implemented in order to store on the client > side >>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>> Currently there is no way in the REST-api to get a "session > token" >>>>>>>>>> (like the cookie sent after a login is made using the web form) > so >>>>>>>>>> that subsequent requests are performed on the behalf of a > previously >>>>>>>>>> authenticated user. >>>>>>>>>> >>>>>>>>>> So what is usually done is to send basic-auth credentials with > each request. >>>>>>>>>> You can start with this. Next you might try to retrieve the > cookie by >>>>>>>>>> faking a standard login and using that cookie in subsequent > requests. >>>>>>>>>> The ideal setting would be to implement server side some > OAuth-like >>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>> >>>>>>>>>> -Fabio >>>>>>>>>> >>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> > wrote: >>>>>>>>>>> Dear all, >>>>>>>>>>> >>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>> >>>>>>>>>>> One question is about how to implement login and logout > functionality >>>>>>>>>>> via REST API. >>>>>>>>>>> From REST API document, users can be authenticated via > something like: >>>>>>>>>>> 1. XWiki session >>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>> >>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the > HTTP >>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing > the response. >>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, I`m pinging you since I don`t know if you were following the little discussion on https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b... based on Fabio's suggestions. Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics. Cheers, Eduard On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote:
Dear all,
After I looked into the current implementation of XEclipse and tried several attempts, one plan, whose goal is to provide an abstract communication layer between XEclipse and server, might be feasible. A rough system diagram showing the relationships of plugins of XWiki Eclipse is available at: http://dl.dropbox.com/u/3466762/xwiki/architecture.png
In order to remove dependency of particular back-end implementation (xmlrpc or rest), an abstract layer, which includes two plugins (model and storage) will be created. 1. model plugin contains the current package of xwiki.eclipse.core.model 2. storage plugin contains xwiki.eclipse.core.storage including two abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage.
In this way, all the core implementation and UI components (dialogs, properties dialog, adapters) in ui plugin will now depend on the model and storage plugins rather than the xmlrpc implementation.
Instead of only providing the required jar files, xmlrpc and rest plugins will also do the following: 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in storage plugin 2. extend the model classes in model plugin
In this way, all the abstract classes in model and storage plugins will be initialized in the run time and perform the specified functions.
If my understanding is correct, I will begin re-factoring work.
Best regards
Jun Han
On 6/11/2011 10:32 AM, Eduard Moraru wrote: > Hi Jun, > > Instead of returning Object, you should return > org.xwiki.eclipse.core.model.Page or Object, etc. > > So the storage abstraction needs to include and abstract model as well in > order to be usable. This means that the implementation also comes with a > model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, > rest.jaxb.model.Page for rest back-end, etc.... all of them implementing > org.xwiki.eclipse.core.model.Page) > > Cheers, > Eduard > > On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: > >> Hi Eduard, >> >> Thanks a lot for prompt instruction. >> >> I forgot to sync the screenshot to the server. Now it is the correct one. >> >> Regarding the pluggable solution for both xml-rpc and rest, I will try >> to devise a common storage API for both of them. >> >> For example, >> public Object getPage(String pageId) >> public List<Object> getPages(String spaceKey) >> >> They will return >> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >> 2. rest.jaxb.model.Page if connecting via rest. >> >> If this is the way to go, I will look more into how to implement this. >> Adapter pattern may be used. >> >> Best regards >> >> Jun Han >> >> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>> Hi, Eduard and Fabio, >>>> >>>> I finished part of the navigation panel, which shows the connection, >>>> wiki, space. >>>> Please see the screenshot at >>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>> I think you pasted the wrong screenshot. We`ve already seen this one and >>> I think it's from an early stage of development. >>>> Adding pages under space is straightforward too, however, it requires >>>> re-factor a lot of source code, which spreads in the plugin of >>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>> >>>> I will continue work on displaying more XWiki resources after I finish >>>> re-factoring the properties editor, action provider (context menu), and >>>> other dialog windows related to connection, wiki, space. >>> It should not take that much of a refactoring on the UI part, since the >>> heavy lifting is done in the core. >>> >>> What I actually wanted to tell you is that you should take the >>> refactoring in a modular direction and consider your work as a >>> contribution and alternative for the existing system and not only as a >>> replacement. I you can`t do it as a contribution, consider adding a >>> mechanism that allows you to do so (see our first discussions on >>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>> model, etc) as the main think the ui and even core components >>> communicate with and keep the implementation of that abstraction layer >>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>> act accordingly. >>> >>> We don`t want to do the same replacement work if, for whatever reason, >>> we want to switch to a different back-end in the future. So keep that in >>> mind at all time during GSoC. >>> >>> Besides that, keep up the good work ;) >>> >>> Thanks, >>> Eduard >>>> Best regards >>>> Jun Han >>>> >>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>> Hi Jun, >>>>>> >>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>> would show this information in the property panel of the connection. >>>>> I think that you should make the "wikis" implicit as well and leave >> only >>>>> the Connection Name as top root, just like in my previous proposal: >>>>> >>>>> Connection01 >>>>> - wiki1 >>>>> -- spaceA >>>>> --- pageX >>>>> - wiki2 >>>>> - etc. >>>>> >>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>> should be displayed in the properties page of a connection. >>>>> >>>>> Also, you need to take care when the user enters the user name and >>>>> password and consider the wiki for which it applies. User Admin on the >>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>> (subwiki1:XWiki.Admin). >>>>> I believe that, if you don`t enter the absolute user name >>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>> will be resolved to the wiki of the resource you are trying to access. >>>>> You should, at least internally, always use absolute user names. >>>>> >>>>> Thanks, >>>>> Eduard >>>>>> Thanks, >>>>>> Fabio >>>>>> >>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >> wrote: >>>>>>> Hi Eduard and Fabio, >>>>>>> >>>>>>> Thanks a lot for your suggestions. >>>>>>> >>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>> >>>>>>> A screenshot is available at: >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>> >>>>>>> Now the labels display the whole<href> attribute, I plan to >> "syntaxes" >>>>>>> and "wikis" later on. >>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>> expand to show all the sub-wiki names. >>>>>>> >>>>>>> It took me a while to figure out the configuration of tree content >>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>> with what I did in Eclipse SWT development. As this has been sorted >> out, >>>>>>> I would pick up the pace. >>>>>>> >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>> account this into the plugin. >>>>>>>> Also, I think that we need to display the other resources (like we >> do >>>>>>>> now), but maybe we should improve that too. >>>>>>>> >>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>> >>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>> ---- Main >>>>>>>> ------ WebHome >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 >>>>>>>> ---------- 1 >>>>>>>> ---------- 2 >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 >>>>>>>> ---------- 1 >>>>>>>> etc. >>>>>>>> >>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >> change >>>>>>>> to some other IDs. >>>>>>>> >>>>>>>> The advantage of such an ordering is that, highly used pages (that >> have >>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>> easier management of the objects. >>>>>>>> >>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>> editor does and you`d have something like: >>>>>>>> >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>> ---------- 1 : Guest >>>>>>>> ---------- 2 : Administrator >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 : etc. >>>>>>>> ---------- 1 : etc. >>>>>>>> etc. >>>>>>>> >>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>> class like: >>>>>>>> >>>>>>>> ------ WebHome >>>>>>>> -------- Attachments >>>>>>>> ---------- dog.png >>>>>>>> ---------- spreadsheet.xls >>>>>>>> -------- XWiki.XWikiComments >>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>> ---------- 1 : Guest >>>>>>>> ---------- 2 : Administrator >>>>>>>> -------- XWiki.MyClass >>>>>>>> ---------- 0 : etc. >>>>>>>> ---------- 1 : etc. >>>>>>>> etc. >>>>>>>> >>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>> again the API specs. >>>>>>>> >>>>>>>> You can get creative with the details on how to display/handle the >> new >>>>>>>> stuff. :) >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Eduard >>>>>>>>> -Fabio >>>>>>>>> >>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >> wrote: >>>>>>>>>> Hi Fabio, >>>>>>>>>> >>>>>>>>>> I have finished replacing xmlrpc implementation of login >> functionality >>>>>>>>>> by sending http GET request to entry point >>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>> >>>>>>>>>> A status code of 200 will be regarded as successful while 401 >> means >>>>>>>>>> login fails. >>>>>>>>>> >>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>> >>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >> code >>>>>>>>>> accordingly. >>>>>>>>>> >>>>>>>>>> One question is what resources are to be included in navigation >> panel, >>>>>>>>>> besides xwiki -> space -> pages? and how to display >> them? >>>>>>>>>> Best regards >>>>>>>>>> >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> login/logout can be implemented in order to store on the client >> side >>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>> Currently there is no way in the REST-api to get a "session >> token" >>>>>>>>>>> (like the cookie sent after a login is made using the web form) >> so >>>>>>>>>>> that subsequent requests are performed on the behalf of a >> previously >>>>>>>>>>> authenticated user. >>>>>>>>>>> >>>>>>>>>>> So what is usually done is to send basic-auth credentials with >> each request. >>>>>>>>>>> You can start with this. Next you might try to retrieve the >> cookie by >>>>>>>>>>> faking a standard login and using that cookie in subsequent >> requests. >>>>>>>>>>> The ideal setting would be to implement server side some >> OAuth-like >>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>> >>>>>>>>>>> -Fabio >>>>>>>>>>> >>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >> wrote: >>>>>>>>>>>> Dear all, >>>>>>>>>>>> >>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>> >>>>>>>>>>>> One question is about how to implement login and logout >> functionality >>>>>>>>>>>> via REST API. >>>>>>>>>>>> From REST API document, users can be authenticated via >> something like: >>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>> >>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >> HTTP >>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >> the response. >>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Jun Han
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
Hi Eduard, I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate. The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. For example, it would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance. I am on the way of re-factoring the code. Best regards Jun Han On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b... based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote:
Hi Jun,
could you post a status about your work? Your commits stream (https://github.com/junhan/xwiki-eclipse/commits/master) is not very informative (are you holding commits locally? If so you should push more frequently!)
Midterm is approaching so we need to make things advance a little bit faster.
Thanks, Fabio
On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: > Dear all, > > After I looked into the current implementation of XEclipse and tried > several attempts, one plan, whose goal is to provide an abstract > communication layer between XEclipse and server, might be feasible. > A rough system diagram showing the relationships of plugins of XWiki > Eclipse is available at: > http://dl.dropbox.com/u/3466762/xwiki/architecture.png > > In order to remove dependency of particular back-end implementation > (xmlrpc or rest), > an abstract layer, which includes two plugins (model and storage) will > be created. > 1. model plugin contains the current package of xwiki.eclipse.core.model > 2. storage plugin contains xwiki.eclipse.core.storage including two > abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. > > In this way, all the core implementation and UI components (dialogs, > properties dialog, adapters) in ui plugin will now depend on the model > and storage plugins rather than the xmlrpc implementation. > > Instead of only providing the required jar files, xmlrpc and rest > plugins will also do the following: > 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in > storage plugin > 2. extend the model classes in model plugin > > In this way, all the abstract classes in model and storage plugins will > be initialized in the run time and perform the specified functions. > > If my understanding is correct, I will begin re-factoring work. > > Best regards > > Jun Han > > On 6/11/2011 10:32 AM, Eduard Moraru wrote: >> Hi Jun, >> >> Instead of returning Object, you should return >> org.xwiki.eclipse.core.model.Page or Object, etc. >> >> So the storage abstraction needs to include and abstract model as well in >> order to be usable. This means that the implementation also comes with a >> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >> org.xwiki.eclipse.core.model.Page) >> >> Cheers, >> Eduard >> >> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >> >>> Hi Eduard, >>> >>> Thanks a lot for prompt instruction. >>> >>> I forgot to sync the screenshot to the server. Now it is the correct one. >>> >>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>> to devise a common storage API for both of them. >>> >>> For example, >>> public Object getPage(String pageId) >>> public List<Object> getPages(String spaceKey) >>> >>> They will return >>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>> 2. rest.jaxb.model.Page if connecting via rest. >>> >>> If this is the way to go, I will look more into how to implement this. >>> Adapter pattern may be used. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>> Hi, Eduard and Fabio, >>>>> >>>>> I finished part of the navigation panel, which shows the connection, >>>>> wiki, space. >>>>> Please see the screenshot at >>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>> I think it's from an early stage of development. >>>>> Adding pages under space is straightforward too, however, it requires >>>>> re-factor a lot of source code, which spreads in the plugin of >>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>> >>>>> I will continue work on displaying more XWiki resources after I finish >>>>> re-factoring the properties editor, action provider (context menu), and >>>>> other dialog windows related to connection, wiki, space. >>>> It should not take that much of a refactoring on the UI part, since the >>>> heavy lifting is done in the core. >>>> >>>> What I actually wanted to tell you is that you should take the >>>> refactoring in a modular direction and consider your work as a >>>> contribution and alternative for the existing system and not only as a >>>> replacement. I you can`t do it as a contribution, consider adding a >>>> mechanism that allows you to do so (see our first discussions on >>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>> model, etc) as the main think the ui and even core components >>>> communicate with and keep the implementation of that abstraction layer >>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>> act accordingly. >>>> >>>> We don`t want to do the same replacement work if, for whatever reason, >>>> we want to switch to a different back-end in the future. So keep that in >>>> mind at all time during GSoC. >>>> >>>> Besides that, keep up the good work ;) >>>> >>>> Thanks, >>>> Eduard >>>>> Best regards >>>>> Jun Han >>>>> >>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>> would show this information in the property panel of the connection. >>>>>> I think that you should make the "wikis" implicit as well and leave >>> only >>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>> >>>>>> Connection01 >>>>>> - wiki1 >>>>>> -- spaceA >>>>>> --- pageX >>>>>> - wiki2 >>>>>> - etc. >>>>>> >>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>> should be displayed in the properties page of a connection. >>>>>> >>>>>> Also, you need to take care when the user enters the user name and >>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>> (subwiki1:XWiki.Admin). >>>>>> I believe that, if you don`t enter the absolute user name >>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>> You should, at least internally, always use absolute user names. >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Thanks, >>>>>>> Fabio >>>>>>> >>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]> >>> wrote: >>>>>>>> Hi Eduard and Fabio, >>>>>>>> >>>>>>>> Thanks a lot for your suggestions. >>>>>>>> >>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>> >>>>>>>> A screenshot is available at: >>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>> >>>>>>>> Now the labels display the whole<href> attribute, I plan to >>> "syntaxes" >>>>>>>> and "wikis" later on. >>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>> expand to show all the sub-wiki names. >>>>>>>> >>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>> out, >>>>>>>> I would pick up the pace. >>>>>>>> >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>> account this into the plugin. >>>>>>>>> Also, I think that we need to display the other resources (like we >>> do >>>>>>>>> now), but maybe we should improve that too. >>>>>>>>> >>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>> >>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>> ---- Main >>>>>>>>> ------ WebHome >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 >>>>>>>>> ---------- 1 >>>>>>>>> ---------- 2 >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 >>>>>>>>> ---------- 1 >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>> change >>>>>>>>> to some other IDs. >>>>>>>>> >>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>> have >>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>> easier management of the objects. >>>>>>>>> >>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>> editor does and you`d have something like: >>>>>>>>> >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>> ---------- 1 : Guest >>>>>>>>> ---------- 2 : Administrator >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 : etc. >>>>>>>>> ---------- 1 : etc. >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>> class like: >>>>>>>>> >>>>>>>>> ------ WebHome >>>>>>>>> -------- Attachments >>>>>>>>> ---------- dog.png >>>>>>>>> ---------- spreadsheet.xls >>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>> ---------- 1 : Guest >>>>>>>>> ---------- 2 : Administrator >>>>>>>>> -------- XWiki.MyClass >>>>>>>>> ---------- 0 : etc. >>>>>>>>> ---------- 1 : etc. >>>>>>>>> etc. >>>>>>>>> >>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>> again the API specs. >>>>>>>>> >>>>>>>>> You can get creative with the details on how to display/handle the >>> new >>>>>>>>> stuff. :) >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> Eduard >>>>>>>>>> -Fabio >>>>>>>>>> >>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han<[email protected]> >>> wrote: >>>>>>>>>>> Hi Fabio, >>>>>>>>>>> >>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>> functionality >>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>> >>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>> means >>>>>>>>>>> login fails. >>>>>>>>>>> >>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>> >>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>> code >>>>>>>>>>> accordingly. >>>>>>>>>>> >>>>>>>>>>> One question is what resources are to be included in navigation >>> panel, >>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>> them? >>>>>>>>>>> Best regards >>>>>>>>>>> >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> login/logout can be implemented in order to store on the client >>> side >>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>> token" >>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>> so >>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>> previously >>>>>>>>>>>> authenticated user. >>>>>>>>>>>> >>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>> each request. >>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>> cookie by >>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>> requests. >>>>>>>>>>>> The ideal setting would be to implement server side some >>> OAuth-like >>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>> >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han<[email protected]> >>> wrote: >>>>>>>>>>>>> Dear all, >>>>>>>>>>>>> >>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is about how to implement login and logout >>> functionality >>>>>>>>>>>>> via REST API. >>>>>>>>>>>>> From REST API document, users can be authenticated via >>> something like: >>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>> >>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>> HTTP >>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>> the response. >>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> Jun Han
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, On Thu, Jun 23, 2011 at 12:14 AM, Jun Han <[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details.
It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages. Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it
it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO.
The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse.
Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
Hi Fabio,
I have already finished re-factoring the whole xmlrpc backend.
A new combo list is added to the "new connection" wizard to provide two choices (xmlrpc and rest), as shown in http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png.
When user selects "xmlrpc", the xmlrpc implementation is used. The navigation panel can show the xwiki resources, as shown in http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png.
I will continue working on the rest backend following the previous discussion.
Best regards
Jun Han
On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: > Hi Jun, > > could you post a status about your work? > Your commits stream > (https://github.com/junhan/xwiki-eclipse/commits/master) is not very > informative (are you holding commits locally? If so you should push > more frequently!) > > Midterm is approaching so we need to make things advance a little bit faster. > > Thanks, > Fabio > > > > On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >> Dear all, >> >> After I looked into the current implementation of XEclipse and tried >> several attempts, one plan, whose goal is to provide an abstract >> communication layer between XEclipse and server, might be feasible. >> A rough system diagram showing the relationships of plugins of XWiki >> Eclipse is available at: >> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >> >> In order to remove dependency of particular back-end implementation >> (xmlrpc or rest), >> an abstract layer, which includes two plugins (model and storage) will >> be created. >> 1. model plugin contains the current package of xwiki.eclipse.core.model >> 2. storage plugin contains xwiki.eclipse.core.storage including two >> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >> >> In this way, all the core implementation and UI components (dialogs, >> properties dialog, adapters) in ui plugin will now depend on the model >> and storage plugins rather than the xmlrpc implementation. >> >> Instead of only providing the required jar files, xmlrpc and rest >> plugins will also do the following: >> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >> storage plugin >> 2. extend the model classes in model plugin >> >> In this way, all the abstract classes in model and storage plugins will >> be initialized in the run time and perform the specified functions. >> >> If my understanding is correct, I will begin re-factoring work. >> >> Best regards >> >> Jun Han >> >> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>> Hi Jun, >>> >>> Instead of returning Object, you should return >>> org.xwiki.eclipse.core.model.Page or Object, etc. >>> >>> So the storage abstraction needs to include and abstract model as well in >>> order to be usable. This means that the implementation also comes with a >>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>> org.xwiki.eclipse.core.model.Page) >>> >>> Cheers, >>> Eduard >>> >>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>> >>>> Hi Eduard, >>>> >>>> Thanks a lot for prompt instruction. >>>> >>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>> >>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>> to devise a common storage API for both of them. >>>> >>>> For example, >>>> public Object getPage(String pageId) >>>> public List<Object> getPages(String spaceKey) >>>> >>>> They will return >>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>> 2. rest.jaxb.model.Page if connecting via rest. >>>> >>>> If this is the way to go, I will look more into how to implement this. >>>> Adapter pattern may be used. >>>> >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>> Hi, Eduard and Fabio, >>>>>> >>>>>> I finished part of the navigation panel, which shows the connection, >>>>>> wiki, space. >>>>>> Please see the screenshot at >>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>> I think it's from an early stage of development. >>>>>> Adding pages under space is straightforward too, however, it requires >>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>> >>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>> other dialog windows related to connection, wiki, space. >>>>> It should not take that much of a refactoring on the UI part, since the >>>>> heavy lifting is done in the core. >>>>> >>>>> What I actually wanted to tell you is that you should take the >>>>> refactoring in a modular direction and consider your work as a >>>>> contribution and alternative for the existing system and not only as a >>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>> mechanism that allows you to do so (see our first discussions on >>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>> model, etc) as the main think the ui and even core components >>>>> communicate with and keep the implementation of that abstraction layer >>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>> act accordingly. >>>>> >>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>> we want to switch to a different back-end in the future. So keep that in >>>>> mind at all time during GSoC. >>>>> >>>>> Besides that, keep up the good work ;) >>>>> >>>>> Thanks, >>>>> Eduard >>>>>> Best regards >>>>>> Jun Han >>>>>> >>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>> would show this information in the property panel of the connection. >>>>>>> I think that you should make the "wikis" implicit as well and leave >>>> only >>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>> >>>>>>> Connection01 >>>>>>> - wiki1 >>>>>>> -- spaceA >>>>>>> --- pageX >>>>>>> - wiki2 >>>>>>> - etc. >>>>>>> >>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>> should be displayed in the properties page of a connection. >>>>>>> >>>>>>> Also, you need to take care when the user enters the user name and >>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>> (subwiki1:XWiki.Admin). >>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>> You should, at least internally, always use absolute user names. >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>>> Thanks, >>>>>>>> Fabio >>>>>>>> >>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected]
>>>> wrote: >>>>>>>>> Hi Eduard and Fabio, >>>>>>>>> >>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>> >>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>> >>>>>>>>> A screenshot is available at: >>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>> >>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>> "syntaxes" >>>>>>>>> and "wikis" later on. >>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>> >>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>> out, >>>>>>>>> I would pick up the pace. >>>>>>>>> >>>>>>>>> Best regards >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>> account this into the plugin. >>>>>>>>>> Also, I think that we need to display the other resources (like we >>>> do >>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>> >>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>> >>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>> ---- Main >>>>>>>>>> ------ WebHome >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 >>>>>>>>>> ---------- 1 >>>>>>>>>> ---------- 2 >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 >>>>>>>>>> ---------- 1 >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>> change >>>>>>>>>> to some other IDs. >>>>>>>>>> >>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>> have >>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>> easier management of the objects. >>>>>>>>>> >>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>> editor does and you`d have something like: >>>>>>>>>> >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>> ---------- 1 : Guest >>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 : etc. >>>>>>>>>> ---------- 1 : etc. >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>> class like: >>>>>>>>>> >>>>>>>>>> ------ WebHome >>>>>>>>>> -------- Attachments >>>>>>>>>> ---------- dog.png >>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>> ---------- 1 : Guest >>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>> ---------- 0 : etc. >>>>>>>>>> ---------- 1 : etc. >>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>> again the API specs. >>>>>>>>>> >>>>>>>>>> You can get creative with the details on how to display/handle the >>>> new >>>>>>>>>> stuff. :) >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Eduard >>>>>>>>>>> -Fabio >>>>>>>>>>> >>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>> wrote: >>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>> >>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>> functionality >>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>> >>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>> means >>>>>>>>>>>> login fails. >>>>>>>>>>>> >>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>> >>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>> code >>>>>>>>>>>> accordingly. >>>>>>>>>>>> >>>>>>>>>>>> One question is what resources are to be included in navigation >>>> panel, >>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>> them? >>>>>>>>>>>> Best regards >>>>>>>>>>>> >>>>>>>>>>>> Jun Han >>>>>>>>>>>> >>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>> side >>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>> token" >>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>> so >>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>> previously >>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>> >>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>> each request. >>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>> cookie by >>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>> requests. >>>>>>>>>>>>> The ideal setting would be to implement server side some >>>> OAuth-like >>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>> >>>>>>>>>>>>> -Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>> wrote: >>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question is about how to implement login and logout >>>> functionality >>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>> something like: >>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>> >>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>> HTTP >>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>> the response. >>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> Jun Han
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Eduard, Per our email discussions, the new system diagram looks like the following figure: http://dl.dropbox.com/u/3466762/xwiki/system%20diagram.png In this way, several goals can be achieved: 1. rest and xmlrpc plugin will only provide functions in their own model, e.g.: jaxb.model or xmlrpc.model. 2. storage plugin contains DataManager, LocalStorage implementation and interface for RemoteDataStorage, and one specific adapter (RestStorage or XmlrpcStorage) will be initialized based on the url of endpoint 3. ui, core, and rcp plugins will not be affected by specific backend implementation. I plan to develop rest and xmlrpc side by side to make sure: 1. each method that is covered in xmlrpc is also implemented in rest (major part) 2. if more APIs are exposed in rest, all the additional APIs will be added (minor part) Best regards Jun Han On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
> Hi Fabio, > > I have already finished re-factoring the whole xmlrpc backend. > > A new combo list is added to the "new connection" wizard to provide two > choices (xmlrpc and rest), as shown in > http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. > > When user selects "xmlrpc", the xmlrpc implementation is used. The > navigation panel can show the xwiki resources, as shown in > http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. > > I will continue working on the rest backend following the previous > discussion. > > Best regards > > Jun Han > > On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> could you post a status about your work? >> Your commits stream >> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >> informative (are you holding commits locally? If so you should push >> more frequently!) >> >> Midterm is approaching so we need to make things advance a little bit faster. >> Thanks, >> Fabio >> >> >> >> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> After I looked into the current implementation of XEclipse and tried >>> several attempts, one plan, whose goal is to provide an abstract >>> communication layer between XEclipse and server, might be feasible. >>> A rough system diagram showing the relationships of plugins of XWiki >>> Eclipse is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>> >>> In order to remove dependency of particular back-end implementation >>> (xmlrpc or rest), >>> an abstract layer, which includes two plugins (model and storage) will >>> be created. >>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>> In this way, all the core implementation and UI components (dialogs, >>> properties dialog, adapters) in ui plugin will now depend on the model >>> and storage plugins rather than the xmlrpc implementation. >>> >>> Instead of only providing the required jar files, xmlrpc and rest >>> plugins will also do the following: >>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>> storage plugin >>> 2. extend the model classes in model plugin >>> >>> In this way, all the abstract classes in model and storage plugins will >>> be initialized in the run time and perform the specified functions. >>> >>> If my understanding is correct, I will begin re-factoring work. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Instead of returning Object, you should return >>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>> >>>> So the storage abstraction needs to include and abstract model as well in >>>> order to be usable. This means that the implementation also comes with a >>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>> org.xwiki.eclipse.core.model.Page) >>>> >>>> Cheers, >>>> Eduard >>>> >>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>> Hi Eduard, >>>>> >>>>> Thanks a lot for prompt instruction. >>>>> >>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>> to devise a common storage API for both of them. >>>>> >>>>> For example, >>>>> public Object getPage(String pageId) >>>>> public List<Object> getPages(String spaceKey) >>>>> >>>>> They will return >>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>> >>>>> If this is the way to go, I will look more into how to implement this. >>>>> Adapter pattern may be used. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>> Hi, Eduard and Fabio, >>>>>>> >>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>> wiki, space. >>>>>>> Please see the screenshot at >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>> I think it's from an early stage of development. >>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>> >>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>> other dialog windows related to connection, wiki, space. >>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>> heavy lifting is done in the core. >>>>>> >>>>>> What I actually wanted to tell you is that you should take the >>>>>> refactoring in a modular direction and consider your work as a >>>>>> contribution and alternative for the existing system and not only as a >>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>> mechanism that allows you to do so (see our first discussions on >>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>> model, etc) as the main think the ui and even core components >>>>>> communicate with and keep the implementation of that abstraction layer >>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>> act accordingly. >>>>>> >>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>> mind at all time during GSoC. >>>>>> >>>>>> Besides that, keep up the good work ;) >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>> would show this information in the property panel of the connection. >>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>> only >>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>> Connection01 >>>>>>>> - wiki1 >>>>>>>> -- spaceA >>>>>>>> --- pageX >>>>>>>> - wiki2 >>>>>>>> - etc. >>>>>>>> >>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>> should be displayed in the properties page of a connection. >>>>>>>> >>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected] >>>>> wrote: >>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>> >>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>> >>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>> >>>>>>>>>> A screenshot is available at: >>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>> "syntaxes" >>>>>>>>>> and "wikis" later on. >>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>> >>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>> out, >>>>>>>>>> I would pick up the pace. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>> account this into the plugin. >>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>> do >>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>> >>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>> ---- Main >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> ---------- 2 >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>> change >>>>>>>>>>> to some other IDs. >>>>>>>>>>> >>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>> have >>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>> easier management of the objects. >>>>>>>>>>> >>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>> >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>> class like: >>>>>>>>>>> >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- Attachments >>>>>>>>>>> ---------- dog.png >>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>> again the API specs. >>>>>>>>>>> >>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>> new >>>>>>>>>>> stuff. :) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Eduard >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>> >>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>> functionality >>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>> means >>>>>>>>>>>>> login fails. >>>>>>>>>>>>> >>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>> code >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>> panel, >>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>> them? >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jun Han >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>> side >>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>> token" >>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>> so >>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>> previously >>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>> each request. >>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>> cookie by >>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>> requests. >>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>> OAuth-like >>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>> functionality >>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>> something like: >>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>> HTTP >>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>> the response. >>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Jun Han _______________________________________________ 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
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
Hi Fabio and Eduard, I have modified the code following the new system diagram: http://dl.dropbox.com/u/3466762/xwiki/system%20diagram.png Now rest and xmlrpc plugins are self-contained, and provide APIs to storage plugin. In storage plugin, two adapter classes, RestRemoteXWikiDataStorageAdapter and XmlrpcRemoteXWikiDataStorageAdapter, provide a wrapper for rest and xmlrpc, respectively. In the two adapters, jaxb.model.SpaceSummary or xmlrpc.model.Space will be converted to XWikiEclipseSpaceSummary class. Therefore, core and ui plugins will not be affected. The navigation of Wiki, Space and Page resources is complete. 1. navigation panel using rest backend: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-MainPage-rest.png 2. navigation panel using xmlrpc backend: http://dl.dropbox.com/u/3466762/xwiki/Screenshot-MainPage-xmlrpc.png I have some questions regarding local storage implementation and hierarchy within page resources, which are listed in a separate email. Best regards Jun Han On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
> Hi Fabio, > > I have already finished re-factoring the whole xmlrpc backend. > > A new combo list is added to the "new connection" wizard to provide two > choices (xmlrpc and rest), as shown in > http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. > > When user selects "xmlrpc", the xmlrpc implementation is used. The > navigation panel can show the xwiki resources, as shown in > http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. > > I will continue working on the rest backend following the previous > discussion. > > Best regards > > Jun Han > > On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> could you post a status about your work? >> Your commits stream >> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >> informative (are you holding commits locally? If so you should push >> more frequently!) >> >> Midterm is approaching so we need to make things advance a little bit faster. >> Thanks, >> Fabio >> >> >> >> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> After I looked into the current implementation of XEclipse and tried >>> several attempts, one plan, whose goal is to provide an abstract >>> communication layer between XEclipse and server, might be feasible. >>> A rough system diagram showing the relationships of plugins of XWiki >>> Eclipse is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>> >>> In order to remove dependency of particular back-end implementation >>> (xmlrpc or rest), >>> an abstract layer, which includes two plugins (model and storage) will >>> be created. >>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>> In this way, all the core implementation and UI components (dialogs, >>> properties dialog, adapters) in ui plugin will now depend on the model >>> and storage plugins rather than the xmlrpc implementation. >>> >>> Instead of only providing the required jar files, xmlrpc and rest >>> plugins will also do the following: >>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>> storage plugin >>> 2. extend the model classes in model plugin >>> >>> In this way, all the abstract classes in model and storage plugins will >>> be initialized in the run time and perform the specified functions. >>> >>> If my understanding is correct, I will begin re-factoring work. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Instead of returning Object, you should return >>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>> >>>> So the storage abstraction needs to include and abstract model as well in >>>> order to be usable. This means that the implementation also comes with a >>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>> org.xwiki.eclipse.core.model.Page) >>>> >>>> Cheers, >>>> Eduard >>>> >>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>> Hi Eduard, >>>>> >>>>> Thanks a lot for prompt instruction. >>>>> >>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>> to devise a common storage API for both of them. >>>>> >>>>> For example, >>>>> public Object getPage(String pageId) >>>>> public List<Object> getPages(String spaceKey) >>>>> >>>>> They will return >>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>> >>>>> If this is the way to go, I will look more into how to implement this. >>>>> Adapter pattern may be used. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>> Hi, Eduard and Fabio, >>>>>>> >>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>> wiki, space. >>>>>>> Please see the screenshot at >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>> I think it's from an early stage of development. >>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>> >>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>> other dialog windows related to connection, wiki, space. >>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>> heavy lifting is done in the core. >>>>>> >>>>>> What I actually wanted to tell you is that you should take the >>>>>> refactoring in a modular direction and consider your work as a >>>>>> contribution and alternative for the existing system and not only as a >>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>> mechanism that allows you to do so (see our first discussions on >>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>> model, etc) as the main think the ui and even core components >>>>>> communicate with and keep the implementation of that abstraction layer >>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>> act accordingly. >>>>>> >>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>> mind at all time during GSoC. >>>>>> >>>>>> Besides that, keep up the good work ;) >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>> would show this information in the property panel of the connection. >>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>> only >>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>> Connection01 >>>>>>>> - wiki1 >>>>>>>> -- spaceA >>>>>>>> --- pageX >>>>>>>> - wiki2 >>>>>>>> - etc. >>>>>>>> >>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>> should be displayed in the properties page of a connection. >>>>>>>> >>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected] >>>>> wrote: >>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>> >>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>> >>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>> >>>>>>>>>> A screenshot is available at: >>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>> "syntaxes" >>>>>>>>>> and "wikis" later on. >>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>> >>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>> out, >>>>>>>>>> I would pick up the pace. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>> account this into the plugin. >>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>> do >>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>> >>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>> ---- Main >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> ---------- 2 >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>> change >>>>>>>>>>> to some other IDs. >>>>>>>>>>> >>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>> have >>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>> easier management of the objects. >>>>>>>>>>> >>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>> >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>> class like: >>>>>>>>>>> >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- Attachments >>>>>>>>>>> ---------- dog.png >>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>> again the API specs. >>>>>>>>>>> >>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>> new >>>>>>>>>>> stuff. :) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Eduard >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>> >>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>> functionality >>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>> means >>>>>>>>>>>>> login fails. >>>>>>>>>>>>> >>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>> code >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>> panel, >>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>> them? >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jun Han >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>> side >>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>> token" >>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>> so >>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>> previously >>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>> each request. >>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>> cookie by >>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>> requests. >>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>> OAuth-like >>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>> functionality >>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>> something like: >>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>> HTTP >>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>> the response. >>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Jun Han _______________________________________________ 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
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
Dear all, I finished the navigation panel for both rest and xmlrpc backend. The screenshots are: 1. http://dl.dropbox.com/u/3466762/xwiki/Screenshot-MainPage-rest-0628.png 2. http://dl.dropbox.com/u/3466762/xwiki/Screenshot-MainPage-xmlrpc-0628.png I am not sure what to return for the label of one page. Right now, I just return pageTitle, but page id seems more appropriate. For example, as indicated in the screenshot, pageId (xwiki:myspace.WebHome) is more informative in my opinion. One improvement is that all the objects with the same className are grouped together. Right now, all the class including tagClass are returned. If we only need comments and annotations, I will modify the code. I will continue working on implementing the add/edit/delete functions. Best regards Jun Han On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
> Hi Fabio, > > I have already finished re-factoring the whole xmlrpc backend. > > A new combo list is added to the "new connection" wizard to provide two > choices (xmlrpc and rest), as shown in > http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. > > When user selects "xmlrpc", the xmlrpc implementation is used. The > navigation panel can show the xwiki resources, as shown in > http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. > > I will continue working on the rest backend following the previous > discussion. > > Best regards > > Jun Han > > On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> could you post a status about your work? >> Your commits stream >> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >> informative (are you holding commits locally? If so you should push >> more frequently!) >> >> Midterm is approaching so we need to make things advance a little bit faster. >> Thanks, >> Fabio >> >> >> >> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> After I looked into the current implementation of XEclipse and tried >>> several attempts, one plan, whose goal is to provide an abstract >>> communication layer between XEclipse and server, might be feasible. >>> A rough system diagram showing the relationships of plugins of XWiki >>> Eclipse is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>> >>> In order to remove dependency of particular back-end implementation >>> (xmlrpc or rest), >>> an abstract layer, which includes two plugins (model and storage) will >>> be created. >>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>> In this way, all the core implementation and UI components (dialogs, >>> properties dialog, adapters) in ui plugin will now depend on the model >>> and storage plugins rather than the xmlrpc implementation. >>> >>> Instead of only providing the required jar files, xmlrpc and rest >>> plugins will also do the following: >>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>> storage plugin >>> 2. extend the model classes in model plugin >>> >>> In this way, all the abstract classes in model and storage plugins will >>> be initialized in the run time and perform the specified functions. >>> >>> If my understanding is correct, I will begin re-factoring work. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Instead of returning Object, you should return >>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>> >>>> So the storage abstraction needs to include and abstract model as well in >>>> order to be usable. This means that the implementation also comes with a >>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>> org.xwiki.eclipse.core.model.Page) >>>> >>>> Cheers, >>>> Eduard >>>> >>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>> Hi Eduard, >>>>> >>>>> Thanks a lot for prompt instruction. >>>>> >>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>> to devise a common storage API for both of them. >>>>> >>>>> For example, >>>>> public Object getPage(String pageId) >>>>> public List<Object> getPages(String spaceKey) >>>>> >>>>> They will return >>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>> >>>>> If this is the way to go, I will look more into how to implement this. >>>>> Adapter pattern may be used. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>> Hi, Eduard and Fabio, >>>>>>> >>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>> wiki, space. >>>>>>> Please see the screenshot at >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>> I think it's from an early stage of development. >>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>> >>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>> other dialog windows related to connection, wiki, space. >>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>> heavy lifting is done in the core. >>>>>> >>>>>> What I actually wanted to tell you is that you should take the >>>>>> refactoring in a modular direction and consider your work as a >>>>>> contribution and alternative for the existing system and not only as a >>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>> mechanism that allows you to do so (see our first discussions on >>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>> model, etc) as the main think the ui and even core components >>>>>> communicate with and keep the implementation of that abstraction layer >>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>> act accordingly. >>>>>> >>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>> mind at all time during GSoC. >>>>>> >>>>>> Besides that, keep up the good work ;) >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>> would show this information in the property panel of the connection. >>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>> only >>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>> Connection01 >>>>>>>> - wiki1 >>>>>>>> -- spaceA >>>>>>>> --- pageX >>>>>>>> - wiki2 >>>>>>>> - etc. >>>>>>>> >>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>> should be displayed in the properties page of a connection. >>>>>>>> >>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected] >>>>> wrote: >>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>> >>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>> >>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>> >>>>>>>>>> A screenshot is available at: >>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>> "syntaxes" >>>>>>>>>> and "wikis" later on. >>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>> >>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>> out, >>>>>>>>>> I would pick up the pace. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>> account this into the plugin. >>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>> do >>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>> >>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>> ---- Main >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> ---------- 2 >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>> change >>>>>>>>>>> to some other IDs. >>>>>>>>>>> >>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>> have >>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>> easier management of the objects. >>>>>>>>>>> >>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>> >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>> class like: >>>>>>>>>>> >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- Attachments >>>>>>>>>>> ---------- dog.png >>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>> again the API specs. >>>>>>>>>>> >>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>> new >>>>>>>>>>> stuff. :) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Eduard >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>> >>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>> functionality >>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>> means >>>>>>>>>>>>> login fails. >>>>>>>>>>>>> >>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>> code >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>> panel, >>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>> them? >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jun Han >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>> side >>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>> token" >>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>> so >>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>> previously >>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>> each request. >>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>> cookie by >>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>> requests. >>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>> OAuth-like >>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>> functionality >>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>> something like: >>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>> HTTP >>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>> the response. >>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Jun Han _______________________________________________ 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
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
Dear all, I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs Now the navigation panel is finished including data connection, and it looks like: data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects. Best regards Jun Han On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote:
Hi there,
I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? Also why do we want to have to maintain several backends?
IMO we should only use one and use the REST API only.
If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. Thanks -Vincent
On Jun 19, 2011, at 6:52 AM, Jun Han wrote:
> Hi Fabio, > > I have already finished re-factoring the whole xmlrpc backend. > > A new combo list is added to the "new connection" wizard to provide two > choices (xmlrpc and rest), as shown in > http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. > > When user selects "xmlrpc", the xmlrpc implementation is used. The > navigation panel can show the xwiki resources, as shown in > http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. > > I will continue working on the rest backend following the previous > discussion. > > Best regards > > Jun Han > > On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >> Hi Jun, >> >> could you post a status about your work? >> Your commits stream >> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >> informative (are you holding commits locally? If so you should push >> more frequently!) >> >> Midterm is approaching so we need to make things advance a little bit faster. >> Thanks, >> Fabio >> >> >> >> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>> Dear all, >>> >>> After I looked into the current implementation of XEclipse and tried >>> several attempts, one plan, whose goal is to provide an abstract >>> communication layer between XEclipse and server, might be feasible. >>> A rough system diagram showing the relationships of plugins of XWiki >>> Eclipse is available at: >>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>> >>> In order to remove dependency of particular back-end implementation >>> (xmlrpc or rest), >>> an abstract layer, which includes two plugins (model and storage) will >>> be created. >>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>> In this way, all the core implementation and UI components (dialogs, >>> properties dialog, adapters) in ui plugin will now depend on the model >>> and storage plugins rather than the xmlrpc implementation. >>> >>> Instead of only providing the required jar files, xmlrpc and rest >>> plugins will also do the following: >>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>> storage plugin >>> 2. extend the model classes in model plugin >>> >>> In this way, all the abstract classes in model and storage plugins will >>> be initialized in the run time and perform the specified functions. >>> >>> If my understanding is correct, I will begin re-factoring work. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>> Hi Jun, >>>> >>>> Instead of returning Object, you should return >>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>> >>>> So the storage abstraction needs to include and abstract model as well in >>>> order to be usable. This means that the implementation also comes with a >>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>> org.xwiki.eclipse.core.model.Page) >>>> >>>> Cheers, >>>> Eduard >>>> >>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>> Hi Eduard, >>>>> >>>>> Thanks a lot for prompt instruction. >>>>> >>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>> to devise a common storage API for both of them. >>>>> >>>>> For example, >>>>> public Object getPage(String pageId) >>>>> public List<Object> getPages(String spaceKey) >>>>> >>>>> They will return >>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>> >>>>> If this is the way to go, I will look more into how to implement this. >>>>> Adapter pattern may be used. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>> Hi, Eduard and Fabio, >>>>>>> >>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>> wiki, space. >>>>>>> Please see the screenshot at >>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>> I think it's from an early stage of development. >>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>> >>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>> other dialog windows related to connection, wiki, space. >>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>> heavy lifting is done in the core. >>>>>> >>>>>> What I actually wanted to tell you is that you should take the >>>>>> refactoring in a modular direction and consider your work as a >>>>>> contribution and alternative for the existing system and not only as a >>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>> mechanism that allows you to do so (see our first discussions on >>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>> model, etc) as the main think the ui and even core components >>>>>> communicate with and keep the implementation of that abstraction layer >>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>> act accordingly. >>>>>> >>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>> mind at all time during GSoC. >>>>>> >>>>>> Besides that, keep up the good work ;) >>>>>> >>>>>> Thanks, >>>>>> Eduard >>>>>>> Best regards >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>> would show this information in the property panel of the connection. >>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>> only >>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>> Connection01 >>>>>>>> - wiki1 >>>>>>>> -- spaceA >>>>>>>> --- pageX >>>>>>>> - wiki2 >>>>>>>> - etc. >>>>>>>> >>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>> should be displayed in the properties page of a connection. >>>>>>>> >>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Thanks, >>>>>>>>> Fabio >>>>>>>>> >>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected] >>>>> wrote: >>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>> >>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>> >>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>> >>>>>>>>>> A screenshot is available at: >>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>> "syntaxes" >>>>>>>>>> and "wikis" later on. >>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>> >>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>> out, >>>>>>>>>> I would pick up the pace. >>>>>>>>>> >>>>>>>>>> Best regards >>>>>>>>>> Jun Han >>>>>>>>>> >>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>> account this into the plugin. >>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>> do >>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>> >>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>> ---- Main >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> ---------- 2 >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 >>>>>>>>>>> ---------- 1 >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>> change >>>>>>>>>>> to some other IDs. >>>>>>>>>>> >>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>> have >>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>> easier management of the objects. >>>>>>>>>>> >>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>> >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>> class like: >>>>>>>>>>> >>>>>>>>>>> ------ WebHome >>>>>>>>>>> -------- Attachments >>>>>>>>>>> ---------- dog.png >>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>> etc. >>>>>>>>>>> >>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>> again the API specs. >>>>>>>>>>> >>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>> new >>>>>>>>>>> stuff. :) >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> Eduard >>>>>>>>>>>> -Fabio >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>> >>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>> functionality >>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>> means >>>>>>>>>>>>> login fails. >>>>>>>>>>>>> >>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>> >>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>> code >>>>>>>>>>>>> accordingly. >>>>>>>>>>>>> >>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>> panel, >>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>> them? >>>>>>>>>>>>> Best regards >>>>>>>>>>>>> >>>>>>>>>>>>> Jun Han >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>> side >>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>> token" >>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>> so >>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>> previously >>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>> >>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>> each request. >>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>> cookie by >>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>> requests. >>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>> OAuth-like >>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>> wrote: >>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>> functionality >>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>> something like: >>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>> HTTP >>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>> the response. >>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> Jun Han _______________________________________________ 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
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
On 07/05/2011 11:47 PM, Jun Han wrote:
Dear all,
I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs
Looks great! Good job so far.
Now the navigation panel is finished including data connection, and it looks like:
data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class
I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects.
-- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi Jun, On Wed, Jul 6, 2011 at 6:47 AM, Jun Han <[email protected]> wrote:
Dear all,
I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs
Now the navigation panel is finished including data connection, and it looks like:
data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class
It's looking really nice so far. Good job. You should also test it on a XEM environment with multiple wikis. Also, some minor details like providing some more consistency in the UI like: 1) Navigator elements should display (local) names everywhere (eg: 'myspace' instead of 'xwiki:myspace'), except for class names that group page objects. 2) In the element property page, you should generally display the full ID of the element ('ID' instead of 'key' in space properties), (local) name and hierarchy information (wiki for a space, space for a page, page for an object) then the other element specific metadata. 3) I would suggest that, for the page class, instead of having 'space.page' as label, you should have a generic label of 'Class'. This might be easier to locate than an ever-changing 'space.class' combination. One note about Annotations is that what you are doing right now, is relying on the AnnotationCode.AnnotationClass objects located in the page. However, the annotation feature is configurable [1], allowing it to use a different (user-specified) annotation class. Besides this level of configuration, it can also have a completely different annotation storage back-end that does not necesarily use XWiki documents to store annotation objects. For the SCRIBO project, we used a different database for storing annotations and provided an annotation storage back-end implementation to use it, so no annotation objects were located in the document itself. There currently exist some [2][3] (undocumented) extensions to the REST API that allow the addition, update and deletion of an annotation and the retrieval of the annotated rendered content plus the list of annotation IDs, but there no possiblity of getting annotation details for an annotation ID (the GET method of the REST resource needs to be implemented). Anyway, let's leave this for now as it is, since it's covering the general usecase and maybe we`ll come back later. Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application... [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... [3] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...
I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects.
Best regards
Jun Han
On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote: > Hi there, > > I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? > Also why do we want to have to maintain several backends? > > IMO we should only use one and use the REST API only. > > If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. > The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. > Thanks > -Vincent > > On Jun 19, 2011, at 6:52 AM, Jun Han wrote: > >> Hi Fabio, >> >> I have already finished re-factoring the whole xmlrpc backend. >> >> A new combo list is added to the "new connection" wizard to provide two >> choices (xmlrpc and rest), as shown in >> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >> >> When user selects "xmlrpc", the xmlrpc implementation is used. The >> navigation panel can show the xwiki resources, as shown in >> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >> >> I will continue working on the rest backend following the previous >> discussion. >> >> Best regards >> >> Jun Han >> >> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> could you post a status about your work? >>> Your commits stream >>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>> informative (are you holding commits locally? If so you should push >>> more frequently!) >>> >>> Midterm is approaching so we need to make things advance a little bit faster. >>> Thanks, >>> Fabio >>> >>> >>> >>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>> Dear all, >>>> >>>> After I looked into the current implementation of XEclipse and tried >>>> several attempts, one plan, whose goal is to provide an abstract >>>> communication layer between XEclipse and server, might be feasible. >>>> A rough system diagram showing the relationships of plugins of XWiki >>>> Eclipse is available at: >>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>> >>>> In order to remove dependency of particular back-end implementation >>>> (xmlrpc or rest), >>>> an abstract layer, which includes two plugins (model and storage) will >>>> be created. >>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>> In this way, all the core implementation and UI components (dialogs, >>>> properties dialog, adapters) in ui plugin will now depend on the model >>>> and storage plugins rather than the xmlrpc implementation. >>>> >>>> Instead of only providing the required jar files, xmlrpc and rest >>>> plugins will also do the following: >>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>> storage plugin >>>> 2. extend the model classes in model plugin >>>> >>>> In this way, all the abstract classes in model and storage plugins will >>>> be initialized in the run time and perform the specified functions. >>>> >>>> If my understanding is correct, I will begin re-factoring work. >>>> >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> Instead of returning Object, you should return >>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>> >>>>> So the storage abstraction needs to include and abstract model as well in >>>>> order to be usable. This means that the implementation also comes with a >>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>> org.xwiki.eclipse.core.model.Page) >>>>> >>>>> Cheers, >>>>> Eduard >>>>> >>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>>> Hi Eduard, >>>>>> >>>>>> Thanks a lot for prompt instruction. >>>>>> >>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>> to devise a common storage API for both of them. >>>>>> >>>>>> For example, >>>>>> public Object getPage(String pageId) >>>>>> public List<Object> getPages(String spaceKey) >>>>>> >>>>>> They will return >>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>> >>>>>> If this is the way to go, I will look more into how to implement this. >>>>>> Adapter pattern may be used. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Jun Han >>>>>> >>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>> Hi, Eduard and Fabio, >>>>>>>> >>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>> wiki, space. >>>>>>>> Please see the screenshot at >>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>> I think it's from an early stage of development. >>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>> >>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>> heavy lifting is done in the core. >>>>>>> >>>>>>> What I actually wanted to tell you is that you should take the >>>>>>> refactoring in a modular direction and consider your work as a >>>>>>> contribution and alternative for the existing system and not only as a >>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>> model, etc) as the main think the ui and even core components >>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>> act accordingly. >>>>>>> >>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>> mind at all time during GSoC. >>>>>>> >>>>>>> Besides that, keep up the good work ;) >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>> only >>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>> Connection01 >>>>>>>>> - wiki1 >>>>>>>>> -- spaceA >>>>>>>>> --- pageX >>>>>>>>> - wiki2 >>>>>>>>> - etc. >>>>>>>>> >>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>> >>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>> Thanks, >>>>>>>>> Eduard >>>>>>>>>> Thanks, >>>>>>>>>> Fabio >>>>>>>>>> >>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han< [email protected] >>>>>> wrote: >>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>> >>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>> >>>>>>>>>>> A screenshot is available at: >>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>> "syntaxes" >>>>>>>>>>> and "wikis" later on. >>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>> >>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>> out, >>>>>>>>>>> I would pick up the pace. >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>> do >>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>> >>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>> ---- Main >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> ---------- 2 >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>> change >>>>>>>>>>>> to some other IDs. >>>>>>>>>>>> >>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>> have >>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>> >>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>> >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>> class like: >>>>>>>>>>>> >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- Attachments >>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>> again the API specs. >>>>>>>>>>>> >>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>> new >>>>>>>>>>>> stuff. :) >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Eduard >>>>>>>>>>>>> -Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>> functionality >>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>> means >>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>> code >>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>> panel, >>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>> them? >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>> side >>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>> token" >>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>> so >>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>> previously >>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>> each request. >>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>> cookie by >>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>> requests. >>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>> OAuth-like >>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>> functionality >>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>> something like: >>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>> HTTP >>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>> the response. >>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>> Jun Han > _______________________________________________ > 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
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Eduard, Thanks a lot for your advice and I will fix the UI issues. I have already tested the multiple wikis against XEM 3.1 stable, and will show it in the next demo. Regarding annotations, I tried to look for a resource Url like: /wikis/{wikiName}/spaces/{spaceName}/pages/{pageName}/annotations in XWiki REST API, but without success. It is great to know that there is a REST resource implementation for it. I will switch from objects to annotation resource as soon as it comes out. Best regards Jun Han On 07/06/2011 09:04 AM, Eduard Moraru wrote:
Hi Jun,
On Wed, Jul 6, 2011 at 6:47 AM, Jun Han<[email protected]> wrote:
Dear all,
I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs
Now the navigation panel is finished including data connection, and it looks like:
data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class
It's looking really nice so far. Good job.
You should also test it on a XEM environment with multiple wikis.
Also, some minor details like providing some more consistency in the UI like: 1) Navigator elements should display (local) names everywhere (eg: 'myspace' instead of 'xwiki:myspace'), except for class names that group page objects. 2) In the element property page, you should generally display the full ID of the element ('ID' instead of 'key' in space properties), (local) name and hierarchy information (wiki for a space, space for a page, page for an object) then the other element specific metadata. 3) I would suggest that, for the page class, instead of having 'space.page' as label, you should have a generic label of 'Class'. This might be easier to locate than an ever-changing 'space.class' combination.
One note about Annotations is that what you are doing right now, is relying on the AnnotationCode.AnnotationClass objects located in the page. However, the annotation feature is configurable [1], allowing it to use a different (user-specified) annotation class. Besides this level of configuration, it can also have a completely different annotation storage back-end that does not necesarily use XWiki documents to store annotation objects. For the SCRIBO project, we used a different database for storing annotations and provided an annotation storage back-end implementation to use it, so no annotation objects were located in the document itself. There currently exist some [2][3] (undocumented) extensions to the REST API that allow the addition, update and deletion of an annotation and the retrieval of the annotated rendered content plus the list of annotation IDs, but there no possiblity of getting annotation details for an annotation ID (the GET method of the REST resource needs to be implemented). Anyway, let's leave this for now as it is, since it's covering the general usecase and maybe we`ll come back later.
Thanks, Eduard
---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application... [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... [3] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik...
I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects.
Best regards
Jun Han
On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote: > Hi Vincent, > > Thanks a lot for your suggestion. > > IMHO, xmlrpc is included for the purpose of back-ward compatibility. > As REST API was first introduced in version 1.8 from xwiki jira, > xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., > v1.4 or v1.5). > > I agree that technical details should not be exposed to end user. > > The backend implementation may be determined via analyzing user input of > server endpoint. For example, if the serverurl contains "confluence" > (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If > it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest > is used. > > However, the current implementation will populate the specific server > url field according to the backend type (xmlrpc or rest). > There may be some better way to do this. > > Best regards > > Jun Han > > On 06/19/2011 03:40 AM, Vincent Massol wrote: >> Hi there, >> >> I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? >> Also why do we want to have to maintain several backends? >> >> IMO we should only use one and use the REST API only. >> >> If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. >> The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. >> Thanks >> -Vincent >> >> On Jun 19, 2011, at 6:52 AM, Jun Han wrote: >> >>> Hi Fabio, >>> >>> I have already finished re-factoring the whole xmlrpc backend. >>> >>> A new combo list is added to the "new connection" wizard to provide two >>> choices (xmlrpc and rest), as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >>> >>> When user selects "xmlrpc", the xmlrpc implementation is used. The >>> navigation panel can show the xwiki resources, as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >>> >>> I will continue working on the rest backend following the previous >>> discussion. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> could you post a status about your work? >>>> Your commits stream >>>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>>> informative (are you holding commits locally? If so you should push >>>> more frequently!) >>>> >>>> Midterm is approaching so we need to make things advance a little bit faster. >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>>> Dear all, >>>>> >>>>> After I looked into the current implementation of XEclipse and tried >>>>> several attempts, one plan, whose goal is to provide an abstract >>>>> communication layer between XEclipse and server, might be feasible. >>>>> A rough system diagram showing the relationships of plugins of XWiki >>>>> Eclipse is available at: >>>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>>> >>>>> In order to remove dependency of particular back-end implementation >>>>> (xmlrpc or rest), >>>>> an abstract layer, which includes two plugins (model and storage) will >>>>> be created. >>>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>>> In this way, all the core implementation and UI components (dialogs, >>>>> properties dialog, adapters) in ui plugin will now depend on the model >>>>> and storage plugins rather than the xmlrpc implementation. >>>>> >>>>> Instead of only providing the required jar files, xmlrpc and rest >>>>> plugins will also do the following: >>>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>>> storage plugin >>>>> 2. extend the model classes in model plugin >>>>> >>>>> In this way, all the abstract classes in model and storage plugins will >>>>> be initialized in the run time and perform the specified functions. >>>>> If my understanding is correct, I will begin re-factoring work. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> Instead of returning Object, you should return >>>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>>> >>>>>> So the storage abstraction needs to include and abstract model as well in >>>>>> order to be usable. This means that the implementation also comes with a >>>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>>> org.xwiki.eclipse.core.model.Page) >>>>>> >>>>>> Cheers, >>>>>> Eduard >>>>>> >>>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>>>> Hi Eduard, >>>>>>> >>>>>>> Thanks a lot for prompt instruction. >>>>>>> >>>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>>> to devise a common storage API for both of them. >>>>>>> >>>>>>> For example, >>>>>>> public Object getPage(String pageId) >>>>>>> public List<Object> getPages(String spaceKey) >>>>>>> >>>>>>> They will return >>>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>>> >>>>>>> If this is the way to go, I will look more into how to implement this. >>>>>>> Adapter pattern may be used. >>>>>>> >>>>>>> Best regards >>>>>>> >>>>>>> Jun Han >>>>>>> >>>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>>> Hi Jun, >>>>>>>> >>>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>>> Hi, Eduard and Fabio, >>>>>>>>> >>>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>>> wiki, space. >>>>>>>>> Please see the screenshot at >>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>>> I think it's from an early stage of development. >>>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>>> >>>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>>> heavy lifting is done in the core. >>>>>>>> >>>>>>>> What I actually wanted to tell you is that you should take the >>>>>>>> refactoring in a modular direction and consider your work as a >>>>>>>> contribution and alternative for the existing system and not only as a >>>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>>> model, etc) as the main think the ui and even core components >>>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>>> act accordingly. >>>>>>>> >>>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>>> mind at all time during GSoC. >>>>>>>> >>>>>>>> Besides that, keep up the good work ;) >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Eduard >>>>>>>>> Best regards >>>>>>>>> Jun Han >>>>>>>>> >>>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>>> Hi Jun, >>>>>>>>>>> >>>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>>> only >>>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>>> Connection01 >>>>>>>>>> - wiki1 >>>>>>>>>> -- spaceA >>>>>>>>>> --- pageX >>>>>>>>>> - wiki2 >>>>>>>>>> - etc. >>>>>>>>>> >>>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>>> >>>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>>> Thanks, >>>>>>>>>> Eduard >>>>>>>>>>> Thanks, >>>>>>>>>>> Fabio >>>>>>>>>>> >>>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han< [email protected] >>>>>>> wrote: >>>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>>> >>>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>>> >>>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>>> >>>>>>>>>>>> A screenshot is available at: >>>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>>> "syntaxes" >>>>>>>>>>>> and "wikis" later on. >>>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>>> >>>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>>> out, >>>>>>>>>>>> I would pick up the pace. >>>>>>>>>>>> >>>>>>>>>>>> Best regards >>>>>>>>>>>> Jun Han >>>>>>>>>>>> >>>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>> >>>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>>> do >>>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>>> >>>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>>> ---- Main >>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>> ---------- 2 >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 >>>>>>>>>>>>> ---------- 1 >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>>> change >>>>>>>>>>>>> to some other IDs. >>>>>>>>>>>>> >>>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>>> have >>>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>>> >>>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>>> >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>>> class like: >>>>>>>>>>>>> >>>>>>>>>>>>> ------ WebHome >>>>>>>>>>>>> -------- Attachments >>>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>>> etc. >>>>>>>>>>>>> >>>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>>> again the API specs. >>>>>>>>>>>>> >>>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>>> new >>>>>>>>>>>>> stuff. :) >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> Eduard >>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>>>> wrote: >>>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>>> functionality >>>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>>> means >>>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>>> code >>>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>>> panel, >>>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>>> them? >>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>>> side >>>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>>> token" >>>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>>> so >>>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>>> previously >>>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>>> each request. >>>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>>> cookie by >>>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>>> requests. >>>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>>> OAuth-like >>>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>>>> wrote: >>>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>>> functionality >>>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>>> something like: >>>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>>> HTTP >>>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>>> the response. >>>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>>> Jun Han >> _______________________________________________ >> 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
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
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear all, I put another short demo for the work I have done. The URL is http://youtu.be/L9UCoa4N8hE The major work includes: 1. grouping various page objects together, e.g., attachment, comment, class, object (annotation and customized class objects) and tags 2. comment resource get comment list and property, create a new comment, reply to an existing comment, (currently, deleting a comment is not supported in REST API yet) 3. attachment resource get attachments and their property, upload a new attachment, update an existing attachment, and remove attachments I am now working on creation and edition of tag, object property and page via REST API. Best regards Jun Han
Hi Jun, On Jul 14, 2011, at 6:14 AM, Jun Han wrote:
Dear all,
I put another short demo for the work I have done. The URL is http://youtu.be/L9UCoa4N8hE
Wow this is really cool! Well done! I'm now eager to start using XEclipse again :) Is there a version I could test (for my mac)? Thanks -Vincent
The major work includes: 1. grouping various page objects together, e.g., attachment, comment, class, object (annotation and customized class objects) and tags 2. comment resource get comment list and property, create a new comment, reply to an existing comment, (currently, deleting a comment is not supported in REST API yet) 3. attachment resource get attachments and their property, upload a new attachment, update an existing attachment, and remove attachments
I am now working on creation and edition of tag, object property and page via REST API.
Best regards
Jun Han
Hi Jun, Looking better and better :) Here are some extra pointers based on your video: 1) Instead of 'Edit' or 'Reply To Comment' buttons in the comment editor, use the standard Save command for an editor and mark the editor window as dirty when it needs saving. Warn the user of an unsaved/modified editor when trying to close it, etc. 1.1) On the same note, I notice that the RCP that you are running does not have the button toolbar. Maybe we should have some common sense buttons like save/save As, undo, cut/copy/paste and maybe some other too. 2) When adding/removing an attachment/comment/page/etc., the general rule should be to refresh as little as possible. So you should refresh just the Attachments/Comments section of the current page and not all the current page's sections (or even worst, the whole navigator). Even better, you could (based on the internal notifications) just add(or remove) the new elements to the UI instead of refreshing everything. All of this minimizes the trafic, reduces waiting time, does not confuse the user and generally helps performance :) Remember that this is a general good practice, but if you have time issues, you could have the first versions just refreshing small sections instead of doing individual manipulations. 3) Just like you did for comments or annotations by displaying the author (first property), you can do the same for general objects, when grouped under their class name. You can just show "[objectNumber] firstPropertyValue". The XWiki object editor treats things a bit more customized [1], preferring the first property matching the pattern "*name*" or "*title*", if not, the first String property and, if that fails too, the first non-TextArea property. (note: the current implementation is a bit buggy and takes the last String or non-TextArea property instead. See [2] for the correct version.) On the other hand, all this "nice" information (first property value) can cause a heavy load on the server since it involves retrieving every single object and getting it's property value. In the object editor, all this info is easily obtained by a database query, but in REST we have to do a lot of queries to get the same data. So if we have 1000 comments on a page or 1000 objects of a specific class, if we try to list them, we will make 1001 requests instead of just 1. Even if this is asynchronous and the user can do something else while the objects are retrieved, the benefit might not be worth it. The debate here is whether to display the first property value for everything like comments, annotations and generic objects (for a better user experience in low-page-load conditions) or for nothing at all (because of the performance overkill). 4) You might want 'Download Attachment' and 'Update Attachment' to be the first actions for an attachment and 'Delete' to be the last. Otherwise, you risk pressing delete unwillingly. It is a general best practice to put destructive actions towards the end of the actions list and main/most used actions towards the top. 5) Minor note: Highlighted Text property of XWikiComments class is not used AFAIK. It's ok to leave it there in case we start using it, but just so you know, I don`t know any place where it is actually used. Maybe it's a step towards merging annotations with comments, but that's another topic of discussion :) Thanks, Eduard ----------- References: [1] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwik... [2] https://github.com/xwiki/xwiki-platform/pull/15/files On Thu, Jul 14, 2011 at 10:04 AM, Vincent Massol <[email protected]> wrote:
Hi Jun,
On Jul 14, 2011, at 6:14 AM, Jun Han wrote:
Dear all,
I put another short demo for the work I have done. The URL is http://youtu.be/L9UCoa4N8hE
Wow this is really cool! Well done!
I'm now eager to start using XEclipse again :)
Is there a version I could test (for my mac)?
Thanks -Vincent
The major work includes: 1. grouping various page objects together, e.g., attachment, comment, class, object (annotation and customized class objects) and tags 2. comment resource get comment list and property, create a new comment, reply to an existing comment, (currently, deleting a comment is not supported in REST API yet) 3. attachment resource get attachments and their property, upload a new attachment, update an existing attachment, and remove attachments
I am now working on creation and edition of tag, object property and page via REST API.
Best regards
Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Eduard, Thanks a lot for your comment. I will modify the source code accordingly. Some reply to your comments are added below. On 07/14/2011 08:40 AM, Eduard Moraru wrote: > Hi Jun, > > Looking better and better :) > > Here are some extra pointers based on your video: > > 1) Instead of 'Edit' or 'Reply To Comment' buttons in the comment editor, > use the standard Save command for an editor and mark the editor window as > dirty when it needs saving. Warn the user of an unsaved/modified editor when > trying to close it, etc. > 1.1) On the same note, I notice that the RCP that you are running does not > have the button toolbar. Maybe we should have some common sense buttons like > save/save As, undo, cut/copy/paste and maybe some other too. The current behavior for comment editor is: 1. user edit comment fields and can save/modify freely, but the save will not submit the comment to server 2. when "new comment" or "reply to " button is clicked, it will gather all the information (saved or unsaved) and submit it to the server, then close the editor even if it contains unsaved information. In the future development, when user click "save" or press "ctrl+s", the information will be saved to local storage. When user click "close", prompt dialog will ask him/her to save it locally or submit to server. I think, we may add button toolbar. But I will postpone it after local storage has been implemented, which is not trivial. > 2) When adding/removing an attachment/comment/page/etc., the general rule > should be to refresh as little as possible. So you should refresh just the > Attachments/Comments section of the current page and not all the current > page's sections (or even worst, the whole navigator). Even better, you could > (based on the internal notifications) just add(or remove) the new elements > to the UI instead of refreshing everything. All of this minimizes the > trafic, reduces waiting time, does not confuse the user and generally helps > performance :) Remember that this is a general good practice, but if you > have time issues, you could have the first versions just refreshing small > sections instead of doing individual manipulations. > I spent a lot of time trying to figure out how to refresh the tree view. However, there is not too much success. When refresh(object) is called, it does not expand the children as expected. I think it might be the reason that refresh(pageSummary) is called instead of refresh(objectCollection). However, two performance issues are that (1) object collection can only be obtained from pageSummary.getChildren() and not available directly from objectCollection's child (e.g., a comment or attachment), (2) from one specific comment, we can only obtain the *"page"* information and not the *"pageSummary"* via REST API. If we only want to only refresh the objectCollection, the current way is to ask server for page summary information, and another way would be to ask local storage, which has not been incorporated yet. > 3) Just like you did for comments or annotations by displaying the author > (first property), you can do the same for general objects, when grouped > under their class name. You can just show "[objectNumber] > firstPropertyValue". The XWiki object editor treats things a bit more > customized [1], preferring the first property matching the pattern "*name*" > or "*title*", if not, the first String property and, if that fails too, the > first non-TextArea property. (note: the current implementation is a bit > buggy and takes the last String or non-TextArea property instead. See [2] > for the correct version.) > > On the other hand, all this "nice" information (first property value) can > cause a heavy load on the server since it involves retrieving every single > object and getting it's property value. In the object editor, all this info > is easily obtained by a database query, but in REST we have to do a lot of > queries to get the same data. So if we have 1000 comments on a page or 1000 > objects of a specific class, if we try to list them, we will make 1001 > requests instead of just 1. Even if this is asynchronous and the user can do > something else while the objects are retrieved, the benefit might not be > worth it. > > The debate here is whether to display the first property value for > everything like comments, annotations and generic objects (for a better user > experience in low-page-load conditions) or for nothing at all (because of > the performance overkill). > This is indeed the case for objects, in order to show the objects identified by its "author' field or other first property. I need to get the object properties first and do a filter based on all the properties. Right now, I filtered out *"comments"* and *"tags"* when displaying objects, as they have dedicated Urls (e.g., ...page/myTestPage/comments, ...page/myTestPage/tags) and thus treated differently. For the comment, make REST call to .../page/myTestpage/comments will give a list of available comments including the "author" and other property fields. Therefore, no need to query object properties further. The current objects category includes *"annotations"* and *"customized class objects"*, which are shown as separate sub-category under "objects". In order to display then, additional calls to object properties have to be performed. But I think, the queries regarding object properties are decreased already, as comments and tags are handled in other Urls. Annotations might cause troubles if there are thousands of them in one page. But I think that is okay for the user who wants to edit the object properties. For 80% users, they may never need to expand the *"objects"*, not to mention its sub-categories. > 4) You might want 'Download Attachment' and 'Update Attachment' to be the > first actions for an attachment and 'Delete' to be the last. Otherwise, you > risk pressing delete unwillingly. It is a general best practice to put > destructive actions towards the end of the actions list and main/most used > actions towards the top. > > 5) Minor note: Highlighted Text property of XWikiComments class is not used > AFAIK. It's ok to leave it there in case we start using it, but just so you > know, I don`t know any place where it is actually used. Maybe it's a step > towards merging annotations with comments, but that's another topic of > discussion :) > > Thanks, > Eduard > > ----------- > References: > [1] > https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-web/src/main/webapp/templates/editobject.vm#L57 > [2] https://github.com/xwiki/xwiki-platform/pull/15/files > > On Thu, Jul 14, 2011 at 10:04 AM, Vincent Massol<[email protected]> wrote: > >> Hi Jun, >> >> On Jul 14, 2011, at 6:14 AM, Jun Han wrote: >> >>> Dear all, >>> >>> I put another short demo for the work I have done. >>> The URL is http://youtu.be/L9UCoa4N8hE >> Wow this is really cool! Well done! >> >> I'm now eager to start using XEclipse again :) >> >> Is there a version I could test (for my mac)? >> >> Thanks >> -Vincent >> >>> The major work includes: >>> 1. grouping various page objects together, e.g., attachment, comment, >>> class, object (annotation and customized class objects) and tags >>> 2. comment resource >>> get comment list and property, create a new comment, reply to an >>> existing comment, (currently, deleting a comment is not supported in >>> REST API yet) >>> 3. attachment resource >>> get attachments and their property, upload a new attachment, update >>> an existing attachment, and remove attachments >>> >>> I am now working on creation and edition of tag, object property and >>> page via REST API. >>> >>> Best regards >>> >>> Jun Han >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs
Dear all, A short demo of the recent work for XEclipse is available at http://youtu.be/5ezeJArS8TE. The major work include: 1. update attachment (support updating attachments of different pages in one batch operation) 2. add a tag/tags to a page 3. open class page 4. open object property, support user and group list 5. new object dialog, improve UI responsiveness by adding a deferredTreeContentManager when loading all of the existing classes 6. open page history 7. open page translation In order to support the local/remote synchronization and page/object creation, the local storage mechanism needs to be implemented and I will work on it in the next week. Best regards Jun Han
On Jul 22, 2011, at 6:42 PM, Jun Han wrote:
Dear all,
A short demo of the recent work for XEclipse is available at http://youtu.be/5ezeJArS8TE.
Very cool again! Does it support XWiki Syntax 2.0 content (page creation in 2.0 syntax, syntax coloring)? The demo shows an example with the 1.0 syntax. Thanks -Vincent
The major work include: 1. update attachment (support updating attachments of different pages in one batch operation) 2. add a tag/tags to a page 3. open class page 4. open object property, support user and group list 5. new object dialog, improve UI responsiveness by adding a deferredTreeContentManager when loading all of the existing classes 6. open page history 7. open page translation
In order to support the local/remote synchronization and page/object creation, the local storage mechanism needs to be implemented and I will work on it in the next week.
Best regards Jun Han
Hi, Vincent, Thanks a lot. It is still 1.0 syntax, as the code for page content editor has not be touched yet. Best regards Jun Han On 07/28/2011 06:03 PM, Vincent Massol wrote:
On Jul 22, 2011, at 6:42 PM, Jun Han wrote:
Dear all,
A short demo of the recent work for XEclipse is available at http://youtu.be/5ezeJArS8TE. Very cool again! Does it support XWiki Syntax 2.0 content (page creation in 2.0 syntax, syntax coloring)? The demo shows an example with the 1.0 syntax.
Thanks -Vincent
The major work include: 1. update attachment (support updating attachments of different pages in one batch operation) 2. add a tag/tags to a page 3. open class page 4. open object property, support user and group list 5. new object dialog, improve UI responsiveness by adding a deferredTreeContentManager when loading all of the existing classes 6. open page history 7. open page translation
In order to support the local/remote synchronization and page/object creation, the local storage mechanism needs to be implemented and I will work on it in the next week.
Best regards Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, Just want to remind you that the official "pencils down" date is in 5 days (15 of August) with some additional wrapping-up and documentation time until the 21st of August (including). Can you please make an overview of your current status and things you might need help with? Thanks, Eduard On Fri, Jul 29, 2011 at 4:05 PM, Jun Han <[email protected]> wrote:
Hi, Vincent,
Thanks a lot.
It is still 1.0 syntax, as the code for page content editor has not be touched yet.
Best regards Jun Han
On 07/28/2011 06:03 PM, Vincent Massol wrote:
On Jul 22, 2011, at 6:42 PM, Jun Han wrote:
Dear all,
A short demo of the recent work for XEclipse is available at http://youtu.be/5ezeJArS8TE. Very cool again! Does it support XWiki Syntax 2.0 content (page creation in 2.0 syntax, syntax coloring)? The demo shows an example with the 1.0 syntax.
Thanks -Vincent
The major work include: 1. update attachment (support updating attachments of different pages in one batch operation) 2. add a tag/tags to a page 3. open class page 4. open object property, support user and group list 5. new object dialog, improve UI responsiveness by adding a deferredTreeContentManager when loading all of the existing classes 6. open page history 7. open page translation
In order to support the local/remote synchronization and page/object creation, the local storage mechanism needs to be implemented and I will work on it in the next week.
Best regards Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear all, The demo video is http://youtu.be/QSKSpgvveHU The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment. Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space Best regards Jun Han
On Aug 10, 2011, at 8:15 PM, Jun Han wrote:
Dear all,
The demo video is http://youtu.be/QSKSpgvveHU
The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment.
Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space
cool cool! I'm really waiting for the XWiki Syntax 2.0 support. IMO this is what is currently missing to make it really usable. Thanks a lot -Vincent
Best regards Jun Han
Hi Jun, On Wed, Aug 10, 2011 at 9:15 PM, Jun Han <[email protected]> wrote:
Dear all,
The demo video is http://youtu.be/QSKSpgvveHU
The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment.
Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space
Great stuff! Some stuff I noticed in the video: - I noticed that the conflict resolution pasted the entire remote content instead of just the conflicting line. Also, the conflict markers showed the entire content as conflicting and not only the specific line(s). Is this a configurable behaviour? Can it just handle conflicting sections(lines)? - Object conflict (do we handle this as well, or just page content?) - No cancelable or background running dialog for the space grabbing. Do you have any more pending issues or stuff you`d like to handle before the end of GSoC? Also, for the remainder of the program, you should mainly focus on cleaning your code, polishing, refactoring (if needed), documenting (and synchronizing the existing code documentation), etc. Thanks, Eduard
Best regards Jun Han
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Eduard, Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. Best regards Jun Han On 08/10/2011 05:03 PM, Eduard Moraru wrote:
Hi Jun,
On Wed, Aug 10, 2011 at 9:15 PM, Jun Han<[email protected]> wrote:
Dear all,
The demo video is http://youtu.be/QSKSpgvveHU
The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment.
Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space
Great stuff!
Some stuff I noticed in the video: - I noticed that the conflict resolution pasted the entire remote content instead of just the conflicting line. Also, the conflict markers showed the entire content as conflicting and not only the specific line(s). Is this a configurable behaviour? Can it just handle conflicting sections(lines)? - Object conflict (do we handle this as well, or just page content?) - No cancelable or background running dialog for the space grabbing.
Do you have any more pending issues or stuff you`d like to handle before the end of GSoC?
Also, for the remainder of the program, you should mainly focus on cleaning your code, polishing, refactoring (if needed), documenting (and synchronizing the existing code documentation), etc.
Thanks, Eduard
Best regards Jun Han
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues.
At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well?
IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
Hi Jun, On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu <[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues.
At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well?
IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation. Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear Vincent, Sergiu and Eduard, Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation. After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal. However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work. Best regards Jun Han On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Aug 13, 2011, at 3:00 AM, Jun Han wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support.
Great!
It would be great that some general guidelines can be given regarding how to achieve this goal.
There are 2 things to consider: 1) Supporting multiple syntaxes. When editing a page in XEclipse you should be able to select the page syntax: xwiki syntax 1.0, xwiki syntax 2.0, xwiki syntax 2.1, jspwiki syntax, confluence syntax, mediawiki syntax, etc. When a page is in a given syntax and another syntax is selected the content must be converted to the new syntax (as it's done in XWiki Enterprise in the wiki and wysiwyg editors). 2) Syntax highlighting. Right now XEclipse support syntax highlighting for XWiki Syntax 1.0. We should at first make sure no syntax highlighting is done for other syntaxes and then add support for highlighting at least XWiki Syntax 2.0 and 2.1 (no need to support highlighting for other syntaxes right now). Same thing for autocomplete. Of course point 1) is the most important. The first part of point 2) is also important (to have syntax highlighting and autocompletion only for XWiki Syntax 1.0). Note: To understand more this concept of multiple syntaxes you could check http://rendering.xwiki.org
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work.
I understand. Thanks -Vincent
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC.
Hi Jun, great work indeed. I am (partially) back from holidays and Eduard just started his. I will review it though Eduard did already a great job (thanks Edy) You can ping me whenever you want for the final phase of the GSoC. Thanks, Fabio On Sat, Aug 13, 2011 at 3:00 AM, Jun Han <[email protected]> wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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
Dear all, My recent work includes the following: 1. fixed XWIKI-6790, which adds copyFrom and moveFrom support for putPage method in RESTful API. 1.1 server side code is added in xwiki-platform, xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/resources/pages/PageResource.java 1.2 test cases are provided in xwiki-enterprise, xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/PageResourceTest.java<https://github.com/junhan/xwiki-enterprise/commit/092c3e109b548a5eee08cb74d4f0aca233eeae7e#diff-0> Pull requests have been initiated for two repos, respectively. 2. implement page rename function via the newly implemented RESTful API in XEclipse 3. improvements: 3.1 add cancel and background running button 3.2 page conflict handling can show multiple conflicts for various sections as long as the sections are separated by one or more blank lines. 3.3 the current object conflicts handling only overrides the values in the remote server with current local values and users cannot select which object properties to synchronize. The current RESTification development almost covers the functions in XEclipse via xmlrpc. A code review will be of great help for me to clean the my code base so that it can be integrated to the main repository. Best regards Jun Han On 08/16/2011 05:53 AM, Fabio Mancinelli wrote:
Hi Jun,
great work indeed. I am (partially) back from holidays and Eduard just started his.
I will review it though Eduard did already a great job (thanks Edy)
You can ping me whenever you want for the final phase of the GSoC.
Thanks, Fabio
On Sat, Aug 13, 2011 at 3:00 AM, Jun Han<[email protected]> wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Dear all, I added a screencast for my recent work. The demo link is http://youtu.be/IAfAcrcx-z0 One part I forgot to mention is XEclipse also can search for pages based on the title and open the selected one. It also support the search for the translation pages if it is stored in local cache. Best regards Jun Han On 08/23/2011 12:59 AM, Jun Han wrote:
Dear all,
My recent work includes the following: 1. fixed XWIKI-6790, which adds copyFrom and moveFrom support for putPage method in RESTful API. 1.1 server side code is added in xwiki-platform, xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/resources/pages/PageResource.java 1.2 test cases are provided in xwiki-enterprise, xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/PageResourceTest.java Pull requests have been initiated for two repos, respectively.
2. implement page rename function via the newly implemented RESTful API in XEclipse
3. improvements: 3.1 add cancel and background running button 3.2 page conflict handling can show multiple conflicts for various sections as long as the sections are separated by one or more blank lines. 3.3 the current object conflicts handling only overrides the values in the remote server with current local values and users cannot select which object properties to synchronize.
The current RESTification development almost covers the functions in XEclipse via xmlrpc. A code review will be of great help for me to clean the my code base so that it can be integrated to the main repository.
Best regards Jun Han
On 08/16/2011 05:53 AM, Fabio Mancinelli wrote:
Hi Jun,
great work indeed. I am (partially) back from holidays and Eduard just started his.
I will review it though Eduard did already a great job (thanks Edy)
You can ping me whenever you want for the final phase of the GSoC.
Thanks, Fabio
On Sat, Aug 13, 2011 at 3:00 AM, Jun Han<[email protected]> wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote:
Hi, Eduard,
Except for the "page rename" function, I do not have other pending issues. At current stage, more of the methods in the adapater class for xmlrpc backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
I will clean and polish the code eventually as well as adding more tests in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, Nice work! The only thing to note is that the rename page functionality is a bit misleading (being combined with copy and all of that). I noticed that you wanted to reuse things, but maybe you should have made 2 separate actions (copy and move/rename) to make things less complicated for the user. Internally, you can reuse the dialog and pass the type as parameter :) Thanks, Eduard On Tue, Aug 23, 2011 at 10:37 PM, Jun Han <[email protected]> wrote:
Dear all,
I added a screencast for my recent work. The demo link is http://youtu.be/IAfAcrcx-z0
One part I forgot to mention is XEclipse also can search for pages based on the title and open the selected one. It also support the search for the translation pages if it is stored in local cache.
Best regards Jun Han
On 08/23/2011 12:59 AM, Jun Han wrote:
Dear all,
My recent work includes the following: 1. fixed XWIKI-6790, which adds copyFrom and moveFrom support for putPage method in RESTful API. 1.1 server side code is added in xwiki-platform,
xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/resources/pages/PageResource.java
1.2 test cases are provided in xwiki-enterprise,
xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/PageResourceTest.java
Pull requests have been initiated for two repos, respectively.
2. implement page rename function via the newly implemented RESTful API in XEclipse
3. improvements: 3.1 add cancel and background running button 3.2 page conflict handling can show multiple conflicts for various sections as long as the sections are separated by one or more blank
lines.
3.3 the current object conflicts handling only overrides the values in the remote server with current local values and users cannot select which object properties to synchronize.
The current RESTification development almost covers the functions in XEclipse via xmlrpc. A code review will be of great help for me to clean the my code base so that it can be integrated to the main repository.
Best regards Jun Han
On 08/16/2011 05:53 AM, Fabio Mancinelli wrote:
Hi Jun,
great work indeed. I am (partially) back from holidays and Eduard just started his.
I will review it though Eduard did already a great job (thanks Edy)
You can ping me whenever you want for the final phase of the GSoC.
Thanks, Fabio
On Sat, Aug 13, 2011 at 3:00 AM, Jun Han<[email protected]> wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with
thesis
and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote:
On 08/11/2011 11:12 AM, Jun Han wrote: > Hi, Eduard, > > Except for the "page rename" function, I do not have other pending issues. > At current stage, more of the methods in the adapater class for xmlrpc > backend are left un-implemented. Do I need to make them work as well? IMO, it's not required for completing the GSoC project, but it would be nice if you have some spare time.
Same opinion as Sergiu. Your main priority is REST + polish&documentation.
Thanks, Eduard
> I will clean and polish the code eventually as well as adding more tests > in the remainder of the GSOC. -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Eduard, Two separate actions (copy page and rename) have been created and implemented. The action combo box letting use to select copy or rename is removed from the rename page dialog. Best regards Jun Han On 08/24/2011 11:10 AM, Eduard Moraru wrote:
Hi Jun,
Nice work!
The only thing to note is that the rename page functionality is a bit misleading (being combined with copy and all of that). I noticed that you wanted to reuse things, but maybe you should have made 2 separate actions (copy and move/rename) to make things less complicated for the user. Internally, you can reuse the dialog and pass the type as parameter :)
Thanks, Eduard
On Tue, Aug 23, 2011 at 10:37 PM, Jun Han<[email protected]> wrote:
Dear all,
I added a screencast for my recent work. The demo link is http://youtu.be/IAfAcrcx-z0
One part I forgot to mention is XEclipse also can search for pages based on the title and open the selected one. It also support the search for the translation pages if it is stored in local cache.
Best regards Jun Han
On 08/23/2011 12:59 AM, Jun Han wrote:
Dear all,
My recent work includes the following: 1. fixed XWIKI-6790, which adds copyFrom and moveFrom support for putPage method in RESTful API. 1.1 server side code is added in xwiki-platform,
xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/resources/pages/PageResource.java
1.2 test cases are provided in xwiki-enterprise,
xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/PageResourceTest.java
Pull requests have been initiated for two repos, respectively.
2. implement page rename function via the newly implemented RESTful API in XEclipse
3. improvements: 3.1 add cancel and background running button 3.2 page conflict handling can show multiple conflicts for various sections as long as the sections are separated by one or more blank
lines.
3.3 the current object conflicts handling only overrides the values in the remote server with current local values and users cannot select which object properties to synchronize.
The current RESTification development almost covers the functions in XEclipse via xmlrpc. A code review will be of great help for me to clean the my code base so that it can be integrated to the main repository.
Best regards Jun Han
On 08/16/2011 05:53 AM, Fabio Mancinelli wrote:
Hi Jun,
great work indeed. I am (partially) back from holidays and Eduard just started his.
I will review it though Eduard did already a great job (thanks Edy)
You can ping me whenever you want for the final phase of the GSoC.
Thanks, Fabio
On Sat, Aug 13, 2011 at 3:00 AM, Jun Han<[email protected]> wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with
thesis
and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote:
Hi Jun,
On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote: > On 08/11/2011 11:12 AM, Jun Han wrote: >> Hi, Eduard, >> >> Except for the "page rename" function, I do not have other pending > issues. >> At current stage, more of the methods in the adapater class for xmlrpc >> backend are left un-implemented. Do I need to make them work as well? > IMO, it's not required for completing the GSoC project, but it would be > nice if you have some spare time. > Same opinion as Sergiu. Your main priority is REST + polish&documentation. Thanks, Eduard
>> I will clean and polish the code eventually as well as adding more tests >> in the remainder of the GSOC. > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > 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
_______________________________________________ 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
Hi Jun, On Wed, Aug 24, 2011 at 9:22 PM, Jun Han <[email protected]> wrote:
Hi, Eduard,
Two separate actions (copy page and rename) have been created and implemented. The action combo box letting use to select copy or rename is removed from the rename page dialog.
Cool! Thanks, Eduard
Best regards Jun Han
On 08/24/2011 11:10 AM, Eduard Moraru wrote:
Hi Jun,
Nice work!
The only thing to note is that the rename page functionality is a bit misleading (being combined with copy and all of that). I noticed that you wanted to reuse things, but maybe you should have made 2 separate actions (copy and move/rename) to make things less complicated for the user. Internally, you can reuse the dialog and pass the type as parameter :)
Thanks, Eduard
On Tue, Aug 23, 2011 at 10:37 PM, Jun Han<[email protected]> wrote:
Dear all,
I added a screencast for my recent work. The demo link is http://youtu.be/IAfAcrcx-z0
One part I forgot to mention is XEclipse also can search for pages based on the title and open the selected one. It also support the search for the translation pages if it is stored in local cache.
Best regards Jun Han
On 08/23/2011 12:59 AM, Jun Han wrote:
Dear all,
My recent work includes the following: 1. fixed XWIKI-6790, which adds copyFrom and moveFrom support for putPage method in RESTful API. 1.1 server side code is added in xwiki-platform,
xwiki-platform-core/xwiki-platform-rest/xwiki-platform-rest-server/src/main/java/org/xwiki/rest/resources/pages/PageResource.java
1.2 test cases are provided in xwiki-enterprise,
xwiki-enterprise-test/xwiki-enterprise-test-rest/src/test/it/org/xwiki/test/rest/PageResourceTest.java
Pull requests have been initiated for two repos, respectively.
2. implement page rename function via the newly implemented RESTful API in XEclipse
3. improvements: 3.1 add cancel and background running button 3.2 page conflict handling can show multiple conflicts for various sections as long as the sections are separated by one or more blank
lines.
3.3 the current object conflicts handling only overrides the values in the remote server with current local values and users cannot select which object properties to synchronize.
The current RESTification development almost covers the functions in XEclipse via xmlrpc. A code review will be of great help for me to clean the my code base so that it can be integrated to the main repository.
Best regards Jun Han
On 08/16/2011 05:53 AM, Fabio Mancinelli wrote:
Hi Jun,
great work indeed. I am (partially) back from holidays and Eduard just started his.
I will review it though Eduard did already a great job (thanks Edy)
You can ping me whenever you want for the final phase of the GSoC.
Thanks, Fabio
On Sat, Aug 13, 2011 at 3:00 AM, Jun Han<[email protected]>
wrote:
Dear Vincent, Sergiu and Eduard,
Before the end of GSOC program, I will focus on rest part, including coding + polishing+ documentation.
After that, I can take a look at adding xwiki syntax 2.0 support. It would be great that some general guidelines can be given regarding how to achieve this goal.
However, the overall development progress might be slow, as the fall semester has already begun in our university, I will be busy with thesis and course work.
Best regards Jun Han
On 8/12/2011 5:22 PM, Eduard Moraru wrote: > Hi Jun, > > On Thu, Aug 11, 2011 at 9:03 PM, Sergiu Dumitriu<[email protected]> wrote: >> On 08/11/2011 11:12 AM, Jun Han wrote: >>> Hi, Eduard, >>> >>> Except for the "page rename" function, I do not have other pending >> issues. >>> At current stage, more of the methods in the adapater class for xmlrpc >>> backend are left un-implemented. Do I need to make them work as well? >> IMO, it's not required for completing the GSoC project, but it would be >> nice if you have some spare time. >> > Same opinion as Sergiu. Your main priority is REST + polish&documentation. > Thanks, > Eduard > > >>> I will clean and polish the code eventually as well as adding more tests >>> in the remainder of the GSOC. >> -- >> Sergiu Dumitriu >> http://purl.org/net/sergiu/ >> _______________________________________________ >> 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
_______________________________________________ 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Aug 10, 2011, at 11:03 PM, Eduard Moraru wrote:
Hi Jun,
On Wed, Aug 10, 2011 at 9:15 PM, Jun Han <[email protected]> wrote:
Dear all,
The demo video is http://youtu.be/QSKSpgvveHU
The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment.
Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space
Great stuff!
Some stuff I noticed in the video: - I noticed that the conflict resolution pasted the entire remote content instead of just the conflicting line. Also, the conflict markers showed the entire content as conflicting and not only the specific line(s). Is this a configurable behaviour? Can it just handle conflicting sections(lines)? - Object conflict (do we handle this as well, or just page content?) - No cancelable or background running dialog for the space grabbing.
Do you have any more pending issues or stuff you`d like to handle before the end of GSoC?
Eduard is supporting XWiki syntax 2.0 part of this SOC? If not then Jun or someone else should add it or find a solution since otherwise all the nice things that Jun has added will be for nothing since XEclipse will not be usable for any real work. Thanks -Vincent
Also, for the remainder of the program, you should mainly focus on cleaning your code, polishing, refactoring (if needed), documenting (and synchronizing the existing code documentation), etc.
Thanks, Eduard
Best regards Jun Han
Hi Vincent, On Thu, Aug 11, 2011 at 10:48 PM, Vincent Massol <[email protected]> wrote:
On Aug 10, 2011, at 11:03 PM, Eduard Moraru wrote:
Hi Jun,
On Wed, Aug 10, 2011 at 9:15 PM, Jun Han <[email protected]> wrote:
Dear all,
The demo video is http://youtu.be/QSKSpgvveHU
The major part of my recent work is listed as below: 1. page creation, modification, synchronization and deletion 2. page translation creation, modification, synchronization and deletion 3. object creation, modification, synchronization and deletion 4. implement the local storage layer using flat file structure and replace xml serialization/de-serialization with JSON 5. Upgrade tycho from v0.11.1 to v0.13.0-SNAPSHOT, which fixes the issue of not being able to generate macOSX product from linux distro. The current maven build script is tested under Fedora 15 and can generate mac OSX x86_64/x86 products successfully. However, I have not tested the functions of generated RCP application in a mac OSX environment.
Some modifications in API and improvements: 1. add and remove tag for a page 2. comment creation and deletion 3. attachment creation, modification and deletion 4. grab space
Great stuff!
Some stuff I noticed in the video: - I noticed that the conflict resolution pasted the entire remote content instead of just the conflicting line. Also, the conflict markers showed the entire content as conflicting and not only the specific line(s). Is this a configurable behaviour? Can it just handle conflicting sections(lines)? - Object conflict (do we handle this as well, or just page content?) - No cancelable or background running dialog for the space grabbing.
Do you have any more pending issues or stuff you`d like to handle before the end of GSoC?
Eduard is supporting XWiki syntax 2.0 part of this SOC? If not then Jun or someone else should add it or find a solution since otherwise all the nice things that Jun has added will be for nothing since XEclipse will not be usable for any real work.
Technically, no, it's not part of the "XEclipse RESTification" project [1]. Now, if Jun would find some time to handle it (not necessarily before the end of GSoC), I`m sure he would get lots of appreciation from our community for the extra work :). If not, I guess I can have a look at it eventually. Thanks, Eduard ----------------- References: [1] http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/#HXEclipse22RESTifica...
Thanks -Vincent
Also, for the remainder of the program, you should mainly focus on cleaning your code, polishing, refactoring (if needed), documenting (and synchronizing the existing code documentation), etc.
Thanks, Eduard
Best regards Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Vincent, There is no XEclipse for MacOS yet, as there are some compilation errors in the code base and the current version of maven build tool (tycho) cannot generate macos application directly (when I tried it last time). I will fix the compilation errors first, then check the newer version of tycho tool and make MacOS application available as soon as possible. Best regards Jun Han On 07/14/2011 03:04 AM, Vincent Massol wrote:
Hi Jun,
On Jul 14, 2011, at 6:14 AM, Jun Han wrote:
Dear all,
I put another short demo for the work I have done. The URL is http://youtu.be/L9UCoa4N8hE Wow this is really cool! Well done!
I'm now eager to start using XEclipse again :)
Is there a version I could test (for my mac)?
Thanks -Vincent
The major work includes: 1. grouping various page objects together, e.g., attachment, comment, class, object (annotation and customized class objects) and tags 2. comment resource get comment list and property, create a new comment, reply to an existing comment, (currently, deleting a comment is not supported in REST API yet) 3. attachment resource get attachments and their property, upload a new attachment, update an existing attachment, and remove attachments
I am now working on creation and edition of tag, object property and page via REST API.
Best regards
Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
On Jul 14, 2011, at 6:06 PM, Jun Han wrote:
Hi Vincent,
There is no XEclipse for MacOS yet, as there are some compilation errors in the code base and the current version of maven build tool (tycho) cannot generate macos application directly (when I tried it last time).
I will fix the compilation errors first, then check the newer version of tycho tool and make MacOS application available as soon as possible.
Thanks! Eagerly waiting -Vincent
Best regards
Jun Han
On 07/14/2011 03:04 AM, Vincent Massol wrote:
Hi Jun,
On Jul 14, 2011, at 6:14 AM, Jun Han wrote:
Dear all,
I put another short demo for the work I have done. The URL is http://youtu.be/L9UCoa4N8hE Wow this is really cool! Well done!
I'm now eager to start using XEclipse again :)
Is there a version I could test (for my mac)?
Thanks -Vincent
The major work includes: 1. grouping various page objects together, e.g., attachment, comment, class, object (annotation and customized class objects) and tags 2. comment resource get comment list and property, create a new comment, reply to an existing comment, (currently, deleting a comment is not supported in REST API yet) 3. attachment resource get attachments and their property, upload a new attachment, update an existing attachment, and remove attachments
I am now working on creation and edition of tag, object property and page via REST API.
Best regards
Jun Han
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jun, sorry for the "radio-silence"... though Eduard did a great Job answering your questions (thanks Edy :)) Very very good job so far! I'll send you some more detailed comments asap. Keep up the good work! -Fabio On Wed, Jul 6, 2011 at 5:47 AM, Jun Han <[email protected]> wrote:
Dear all,
I uploaded a short demo video in youtube to show the current status of XEclipse. The URL is http://youtu.be/TwuNjg1XoUs
Now the navigation panel is finished including data connection, and it looks like:
data connection |- wiki |- space |- page, |-- attachment |-- comment |-- annotation |-- tag |-- page class
I will continue working on: (1) re-factor xmlrpc backend (2) modify the local storage API and apply a flat structure for the local cached objects.
Best regards
Jun Han
On 06/23/2011 05:55 AM, Eduard Moraru wrote:
Hi Jun,
On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote:
Hi Eduard,
I think I understand what you and Fabio discussed regarding the model package. My current implementation looks like the following: AbstractXWikiEclipsePage / \ RestPage XmlrpcPage where RestPage wraps jaxb.model.Page and XmlrpcPage wraps xmlrpc.model.Page. This introduces 3 model packages, which is not appropriate.
The suggestion from Fabio and you is to remove the redundancy and various DataManager implementation will take care the model details. It's not the DataManager implementations that need to take care of that. DataManager is a final class in the org.xwiki.eclipse.storage plugin that uses remote or local data storages.
Each storage plugin implements RemoteXWikiDataStorage, accepts and outputs org.xwiki.eclipse.model entities.
For example, it it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage
Thanks, Eduard
would manipulate either jaxb.model.Page or xmlrpc.model.Page and returns the XWikiEclipsePage instance.
I am on the way of re-factoring the code.
Best regards
Jun Han
On 06/22/2011 07:22 AM, Eduard Moraru wrote:
Hi Jun,
I`m pinging you since I don`t know if you were following the little discussion on
https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b...
based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics.
Cheers, Eduard
On 06/20/2011 08:10 PM, Fabio Mancinelli wrote:
Hi Jun,
I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look.
Thanks, Fabio
On Sun, Jun 19, 2011 at 4:57 PM, Jun Han<[email protected]> wrote:
Hi Vincent,
Thanks a lot for your suggestion.
IMHO, xmlrpc is included for the purpose of back-ward compatibility. As REST API was first introduced in version 1.8 from xwiki jira, xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., v1.4 or v1.5).
I agree that technical details should not be exposed to end user.
The backend implementation may be determined via analyzing user input of server endpoint. For example, if the serverurl contains "confluence" (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest is used.
However, the current implementation will populate the specific server url field according to the backend type (xmlrpc or rest). There may be some better way to do this.
Best regards
Jun Han
On 06/19/2011 03:40 AM, Vincent Massol wrote: > Hi there, > > I haven't followed this thread but just noticing this: why do we want to expose to users something purely technical (ie the backend implementation)? > Also why do we want to have to maintain several backends? > > IMO we should only use one and use the REST API only. > > If it's only about migration from the current XMLRPC to REST, it should be a "hidden" config param not exposed to users and that we use internally only IMO. > The goal should always be to make it as easy as possible for end users, i.e. they shouldn't have to think when using XEclipse. > Thanks > -Vincent > > On Jun 19, 2011, at 6:52 AM, Jun Han wrote: > >> Hi Fabio, >> >> I have already finished re-factoring the whole xmlrpc backend. >> >> A new combo list is added to the "new connection" wizard to provide two >> choices (xmlrpc and rest), as shown in >> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >> >> When user selects "xmlrpc", the xmlrpc implementation is used. The >> navigation panel can show the xwiki resources, as shown in >> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >> >> I will continue working on the rest backend following the previous >> discussion. >> >> Best regards >> >> Jun Han >> >> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>> Hi Jun, >>> >>> could you post a status about your work? >>> Your commits stream >>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>> informative (are you holding commits locally? If so you should push >>> more frequently!) >>> >>> Midterm is approaching so we need to make things advance a little bit faster. >>> Thanks, >>> Fabio >>> >>> >>> >>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>> Dear all, >>>> >>>> After I looked into the current implementation of XEclipse and tried >>>> several attempts, one plan, whose goal is to provide an abstract >>>> communication layer between XEclipse and server, might be feasible. >>>> A rough system diagram showing the relationships of plugins of XWiki >>>> Eclipse is available at: >>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>> >>>> In order to remove dependency of particular back-end implementation >>>> (xmlrpc or rest), >>>> an abstract layer, which includes two plugins (model and storage) will >>>> be created. >>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>> In this way, all the core implementation and UI components (dialogs, >>>> properties dialog, adapters) in ui plugin will now depend on the model >>>> and storage plugins rather than the xmlrpc implementation. >>>> >>>> Instead of only providing the required jar files, xmlrpc and rest >>>> plugins will also do the following: >>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>> storage plugin >>>> 2. extend the model classes in model plugin >>>> >>>> In this way, all the abstract classes in model and storage plugins will >>>> be initialized in the run time and perform the specified functions. >>>> >>>> If my understanding is correct, I will begin re-factoring work. >>>> >>>> Best regards >>>> >>>> Jun Han >>>> >>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>> Hi Jun, >>>>> >>>>> Instead of returning Object, you should return >>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>> >>>>> So the storage abstraction needs to include and abstract model as well in >>>>> order to be usable. This means that the implementation also comes with a >>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>> org.xwiki.eclipse.core.model.Page) >>>>> >>>>> Cheers, >>>>> Eduard >>>>> >>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>>> Hi Eduard, >>>>>> >>>>>> Thanks a lot for prompt instruction. >>>>>> >>>>>> I forgot to sync the screenshot to the server. Now it is the correct one. >>>>>> Regarding the pluggable solution for both xml-rpc and rest, I will try >>>>>> to devise a common storage API for both of them. >>>>>> >>>>>> For example, >>>>>> public Object getPage(String pageId) >>>>>> public List<Object> getPages(String spaceKey) >>>>>> >>>>>> They will return >>>>>> 1. xmlrpc.model.PageSummary if connecting via xmlrpc or >>>>>> 2. rest.jaxb.model.Page if connecting via rest. >>>>>> >>>>>> If this is the way to go, I will look more into how to implement this. >>>>>> Adapter pattern may be used. >>>>>> >>>>>> Best regards >>>>>> >>>>>> Jun Han >>>>>> >>>>>> On 06/10/2011 12:08 PM, Eduard Moraru wrote: >>>>>>> Hi Jun, >>>>>>> >>>>>>> On 06/10/2011 05:26 PM, Jun Han wrote: >>>>>>>> Hi, Eduard and Fabio, >>>>>>>> >>>>>>>> I finished part of the navigation panel, which shows the connection, >>>>>>>> wiki, space. >>>>>>>> Please see the screenshot at >>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>> I think you pasted the wrong screenshot. We`ve already seen this one and >>>>>>> I think it's from an early stage of development. >>>>>>>> Adding pages under space is straightforward too, however, it requires >>>>>>>> re-factor a lot of source code, which spreads in the plugin of >>>>>>>> xwiki.eclipse.ui and xwiki.eclipse.core. >>>>>>>> >>>>>>>> I will continue work on displaying more XWiki resources after I finish >>>>>>>> re-factoring the properties editor, action provider (context menu), and >>>>>>>> other dialog windows related to connection, wiki, space. >>>>>>> It should not take that much of a refactoring on the UI part, since the >>>>>>> heavy lifting is done in the core. >>>>>>> >>>>>>> What I actually wanted to tell you is that you should take the >>>>>>> refactoring in a modular direction and consider your work as a >>>>>>> contribution and alternative for the existing system and not only as a >>>>>>> replacement. I you can`t do it as a contribution, consider adding a >>>>>>> mechanism that allows you to do so (see our first discussions on >>>>>>> integrating the rest back-end). Keep the abstraction layer (interfaces, >>>>>>> model, etc) as the main think the ui and even core components >>>>>>> communicate with and keep the implementation of that abstraction layer >>>>>>> pluggable (xml-rpc, rest, etc). The UI must also be aware of this and >>>>>>> act accordingly. >>>>>>> >>>>>>> We don`t want to do the same replacement work if, for whatever reason, >>>>>>> we want to switch to a different back-end in the future. So keep that in >>>>>>> mind at all time during GSoC. >>>>>>> >>>>>>> Besides that, keep up the good work ;) >>>>>>> >>>>>>> Thanks, >>>>>>> Eduard >>>>>>>> Best regards >>>>>>>> Jun Han >>>>>>>> >>>>>>>> On 06/09/2011 07:26 PM, Eduard Moraru wrote: >>>>>>>>> Hi Jun, >>>>>>>>> >>>>>>>>> On 06/09/2011 11:14 AM, Fabio Mancinelli wrote: >>>>>>>>>> Hi Jun, >>>>>>>>>> >>>>>>>>>> I am not sure that syntaxes should appear as a child of connection. I >>>>>>>>>> would show this information in the property panel of the connection. >>>>>>>>> I think that you should make the "wikis" implicit as well and leave >>>>>> only >>>>>>>>> the Connection Name as top root, just like in my previous proposal: >>>>>>>>> Connection01 >>>>>>>>> - wiki1 >>>>>>>>> -- spaceA >>>>>>>>> --- pageX >>>>>>>>> - wiki2 >>>>>>>>> - etc. >>>>>>>>> >>>>>>>>> As Fabio pointed out, stuff like supported syntaxes and xwiki version >>>>>>>>> should be displayed in the properties page of a connection. >>>>>>>>> >>>>>>>>> Also, you need to take care when the user enters the user name and >>>>>>>>> password and consider the wiki for which it applies. User Admin on the >>>>>>>>> main wiki (xwiki:XWiki.Admin) is not the same as user Admin on subwiki1 >>>>>>>>> (subwiki1:XWiki.Admin). >>>>>>>>> I believe that, if you don`t enter the absolute user name >>>>>>>>> (xwiki:XWiki.Admin) and you enter only the relative name (Admin), it >>>>>>>>> will be resolved to the wiki of the resource you are trying to access. >>>>>>>>> You should, at least internally, always use absolute user names. >>>>>>>>> Thanks, >>>>>>>>> Eduard >>>>>>>>>> Thanks, >>>>>>>>>> Fabio >>>>>>>>>> >>>>>>>>>> On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<[email protected] >>>>>> wrote: >>>>>>>>>>> Hi Eduard and Fabio, >>>>>>>>>>> >>>>>>>>>>> Thanks a lot for your suggestions. >>>>>>>>>>> >>>>>>>>>>> I managed to create a top-level tree expansion when user requests the >>>>>>>>>>> entry point of REST API: localhost:8080/xwiki/rest. >>>>>>>>>>> >>>>>>>>>>> A screenshot is available at: >>>>>>>>>>> http://dl.dropbox.com/u/3466762/xwiki/Screenshot-navigationPanel.png >>>>>>>>>>> Now the labels display the whole<href> attribute, I plan to >>>>>> "syntaxes" >>>>>>>>>>> and "wikis" later on. >>>>>>>>>>> When user clicks the "wikis", the navigation tree will continue to >>>>>>>>>>> expand to show all the sub-wiki names. >>>>>>>>>>> >>>>>>>>>>> It took me a while to figure out the configuration of tree content >>>>>>>>>>> provider, tree viewer and label provider, which is a little different >>>>>>>>>>> with what I did in Eclipse SWT development. As this has been sorted >>>>>> out, >>>>>>>>>>> I would pick up the pace. >>>>>>>>>>> >>>>>>>>>>> Best regards >>>>>>>>>>> Jun Han >>>>>>>>>>> >>>>>>>>>>> On 06/07/2011 10:37 AM, Eduard Moraru wrote: >>>>>>>>>>>> Hi Jun, >>>>>>>>>>>> >>>>>>>>>>>> On 06/07/2011 02:05 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>> >>>>>>>>>>>>> the REST api also takes into account Wikis, so you should take into >>>>>>>>>>>>> account this into the plugin. >>>>>>>>>>>> Also, I think that we need to display the other resources (like we >>>>>> do >>>>>>>>>>>> now), but maybe we should improve that too. >>>>>>>>>>>> >>>>>>>>>>>> I`d suggest that we group objects by class name, something like: >>>>>>>>>>>> xwiki.org (wiki/farm/connection name, given by the user) >>>>>>>>>>>> -- xwiki (main/sub wiki name) >>>>>>>>>>>> ---- Main >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> ---------- 2 >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 >>>>>>>>>>>> ---------- 1 >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> 0, 1, 2 above are object numbers, but, in the future, they might >>>>>> change >>>>>>>>>>>> to some other IDs. >>>>>>>>>>>> >>>>>>>>>>>> The advantage of such an ordering is that, highly used pages (that >>>>>> have >>>>>>>>>>>> lots of comments, or lots of objects of specific classes) will allow >>>>>>>>>>>> easier management of the objects. >>>>>>>>>>>> >>>>>>>>>>>> If a list of numbers looks too blank, you could have them print the >>>>>>>>>>>> value of the first property it their class, just like XWiki`s object >>>>>>>>>>>> editor does and you`d have something like: >>>>>>>>>>>> >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> I don`t know what's the status of Attachments (I don remember if we >>>>>>>>>>>> display them or not), but we should have them as an 'implicit' first >>>>>>>>>>>> class like: >>>>>>>>>>>> >>>>>>>>>>>> ------ WebHome >>>>>>>>>>>> -------- Attachments >>>>>>>>>>>> ---------- dog.png >>>>>>>>>>>> ---------- spreadsheet.xls >>>>>>>>>>>> -------- XWiki.XWikiComments >>>>>>>>>>>> ---------- 0 : Administrator ('author' property value) >>>>>>>>>>>> ---------- 1 : Guest >>>>>>>>>>>> ---------- 2 : Administrator >>>>>>>>>>>> -------- XWiki.MyClass >>>>>>>>>>>> ---------- 0 : etc. >>>>>>>>>>>> ---------- 1 : etc. >>>>>>>>>>>> etc. >>>>>>>>>>>> >>>>>>>>>>>> Anyway, the main idea is to expose as much as REST API allows. Check >>>>>>>>>>>> again the API specs. >>>>>>>>>>>> >>>>>>>>>>>> You can get creative with the details on how to display/handle the >>>>>> new >>>>>>>>>>>> stuff. :) >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> Eduard >>>>>>>>>>>>> -Fabio >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>> Hi Fabio, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have finished replacing xmlrpc implementation of login >>>>>> functionality >>>>>>>>>>>>>> by sending http GET request to entry point >>>>>>>>>>>>>> (http://localhost:8080/xwiki/rest/) along with username/password. >>>>>>>>>>>>>> A status code of 200 will be regarded as successful while 401 >>>>>> means >>>>>>>>>>>>>> login fails. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The source code have been updated in org.xwiki.eclipse.ui and >>>>>>>>>>>>>> org.xwiki.eclipse.core plugins. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will begin working on xwiki navigatoin panel and replace xmlrpc >>>>>> code >>>>>>>>>>>>>> accordingly. >>>>>>>>>>>>>> >>>>>>>>>>>>>> One question is what resources are to be included in navigation >>>>>> panel, >>>>>>>>>>>>>> besides xwiki -> space -> pages? and how to display >>>>>> them? >>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>> >>>>>>>>>>>>>> Jun Han >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 06/05/2011 05:50 PM, Fabio Mancinelli wrote: >>>>>>>>>>>>>>> Hi Jun, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> login/logout can be implemented in order to store on the client >>>>>> side >>>>>>>>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>>>>>>>>> Currently there is no way in the REST-api to get a "session >>>>>> token" >>>>>>>>>>>>>>> (like the cookie sent after a login is made using the web form) >>>>>> so >>>>>>>>>>>>>>> that subsequent requests are performed on the behalf of a >>>>>> previously >>>>>>>>>>>>>>> authenticated user. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> So what is usually done is to send basic-auth credentials with >>>>>> each request. >>>>>>>>>>>>>>> You can start with this. Next you might try to retrieve the >>>>>> cookie by >>>>>>>>>>>>>>> faking a standard login and using that cookie in subsequent >>>>>> requests. >>>>>>>>>>>>>>> The ideal setting would be to implement server side some >>>>>> OAuth-like >>>>>>>>>>>>>>> mechanism, but this is out of scope wrt your project. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -Fabio >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Sat, Jun 4, 2011 at 6:27 PM, Jun Han< [email protected]> >>>>>> wrote: >>>>>>>>>>>>>>>> Dear all, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I am on the way of replacing the xmlrpc implementation of >>>>>>>>>>>>>>>> RemoteXWikiDataStorage implements IDataStorage {}. >>>>>>>>>>>>>>>> One question is about how to implement login and logout >>>>>> functionality >>>>>>>>>>>>>>>> via REST API. >>>>>>>>>>>>>>>> From REST API document, users can be authenticated via >>>>>> something like: >>>>>>>>>>>>>>>> 1. XWiki session >>>>>>>>>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the >>>>>> HTTP >>>>>>>>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing >>>>>> the response. >>>>>>>>>>>>>>>> Therefore, do we need to implement login and logout methods? >>>>>>>>>>>>>>>> Best regards >>>>>>>>>>>>>>>> Jun Han > _______________________________________________ > 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
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Eduard Moraru -
Eduard Moraru -
Fabio Mancinelli -
Florin Ciubotaru -
Jun Han -
Paul Libbrecht -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol