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

Hi Jun, On 06/10/2011 05:26 PM, Jun Han wrote: I think you pasted the wrong screenshot. We`ve already seen this one and I think it's from an early stage of development. 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

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

>>>> 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

>>>> 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

>>>> 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

>>>>> 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

>>>>> to some other IDs. >>>>> >>>>> The advantage of such an ordering is that, highly used pages (that

>>>>> 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

>>>>> stuff. :) >>>>> >>>>> Cheers, >>>>> Eduard >>>>>> -Fabio >>>>>> >>>>>> On Tue, Jun 7, 2011 at 7:35 AM, Jun Han&lt;jun.han37(a)gmail.com&gt;

>>>>>>> Hi Fabio, >>>>>>> >>>>>>> I have finished replacing xmlrpc implementation of login

>>>>>>> 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

>>>>>>> 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

>>>>>>> accordingly. >>>>>>> >>>>>>> One question is what resources are to be included in navigation

>>>>>>> besides xwiki -> space -> pages? and how to display

>>>>>>> >>>>>>> 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

>>>>>>>> user credentials that are sent with HTTP requests. >>>>>>>> Currently there is no way in the REST-api to get a "session

>>>>>>>> (like the cookie sent after a login is made using the web form)

>>>>>>>> that subsequent requests are performed on the behalf of a

>>>>>>>> authenticated user. >>>>>>>> >>>>>>>> So what is usually done is to send basic-auth credentials with

>>>>>>>> >>>>>>>> You can start with this. Next you might try to retrieve the

>>>>>>>> faking a standard login and using that cookie in subsequent

>>>>>>>> >>>>>>>> The ideal setting would be to implement server side some

>>>>>>>> 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;

>>>>>>>>> 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

>>>>>>>>> via REST API. >>>>>>>>> From REST API document, users can be authenticated via

>>>>>>>>> 1. XWiki session >>>>>>>>> 2. HTTP Basic Auth. >>>>>>>>> >>>>>>>>> HTTP basic auth can be implemented via adding HTTP header to the

>>>>>>>>> request, then XEclipse can display Xwiki Resources by parsing

_______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs