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
