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
