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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
