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