Re: [xwiki-devs] [GSoC] XEclipse RESTification

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&lt;jun.han37(a)gmail.com&gt;   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&lt;jun.han37(a)gmail.com&gt;     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&lt;jun.han37(a)gmail.com&gt; >>>> 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&lt;jun.han37(a)gmail.com&gt; >>>>    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&lt;jun.han37(a)gmail.com&gt; >>>>        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