Hi Jun, I did a code review in your branch. I've written a lot of notes in the commits (you should have received several mail for that :))
Please take a look. Thanks, Fabio On Sun, Jun 19, 2011 at 4:57 PM, Jun Han <[email protected]> wrote: > Hi Vincent, > > Thanks a lot for your suggestion. > > IMHO, xmlrpc is included for the purpose of back-ward compatibility. > As REST API was first introduced in version 1.8 from xwiki jira, > xmlrpc might be useful If the xwiki server only supports xmlrpc (e.g., > v1.4 or v1.5). > > I agree that technical details should not be exposed to end user. > > The backend implementation may be determined via analyzing user input of > server endpoint. For example, if the serverurl contains "confluence" > (http://localhost:8080/xwiki/xmlrpc/confluence), then xmlrpc is used. If > it contains "rest" (e.g., http://localhost:8080/xwiki/rest), then rest > is used. > > However, the current implementation will populate the specific server > url field according to the backend type (xmlrpc or rest). > There may be some better way to do this. > > Best regards > > Jun Han > > On 06/19/2011 03:40 AM, Vincent Massol wrote: >> Hi there, >> >> I haven't followed this thread but just noticing this: why do we want to >> expose to users something purely technical (ie the backend implementation)? >> Also why do we want to have to maintain several backends? >> >> IMO we should only use one and use the REST API only. >> >> If it's only about migration from the current XMLRPC to REST, it should be a >> "hidden" config param not exposed to users and that we use internally only >> IMO. >> >> The goal should always be to make it as easy as possible for end users, i.e. >> they shouldn't have to think when using XEclipse. >> >> Thanks >> -Vincent >> >> On Jun 19, 2011, at 6:52 AM, Jun Han wrote: >> >>> Hi Fabio, >>> >>> I have already finished re-factoring the whole xmlrpc backend. >>> >>> A new combo list is added to the "new connection" wizard to provide two >>> choices (xmlrpc and rest), as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/newConnectionWizard.png. >>> >>> When user selects "xmlrpc", the xmlrpc implementation is used. The >>> navigation panel can show the xwiki resources, as shown in >>> http://dl.dropbox.com/u/3466762/xwiki/xmlrpcBackend.png. >>> >>> I will continue working on the rest backend following the previous >>> discussion. >>> >>> Best regards >>> >>> Jun Han >>> >>> On 06/17/2011 09:24 AM, Fabio Mancinelli wrote: >>>> Hi Jun, >>>> >>>> could you post a status about your work? >>>> Your commits stream >>>> (https://github.com/junhan/xwiki-eclipse/commits/master) is not very >>>> informative (are you holding commits locally? If so you should push >>>> more frequently!) >>>> >>>> Midterm is approaching so we need to make things advance a little bit >>>> faster. >>>> >>>> Thanks, >>>> Fabio >>>> >>>> >>>> >>>> On Mon, Jun 13, 2011 at 9:00 AM, Jun Han<[email protected]> wrote: >>>>> Dear all, >>>>> >>>>> After I looked into the current implementation of XEclipse and tried >>>>> several attempts, one plan, whose goal is to provide an abstract >>>>> communication layer between XEclipse and server, might be feasible. >>>>> A rough system diagram showing the relationships of plugins of XWiki >>>>> Eclipse is available at: >>>>> http://dl.dropbox.com/u/3466762/xwiki/architecture.png >>>>> >>>>> In order to remove dependency of particular back-end implementation >>>>> (xmlrpc or rest), >>>>> an abstract layer, which includes two plugins (model and storage) will >>>>> be created. >>>>> 1. model plugin contains the current package of xwiki.eclipse.core.model >>>>> 2. storage plugin contains xwiki.eclipse.core.storage including two >>>>> abstract classes, AbstractLocalDataStorage and AbstractRemoteDataStorage. >>>>> >>>>> In this way, all the core implementation and UI components (dialogs, >>>>> properties dialog, adapters) in ui plugin will now depend on the model >>>>> and storage plugins rather than the xmlrpc implementation. >>>>> >>>>> Instead of only providing the required jar files, xmlrpc and rest >>>>> plugins will also do the following: >>>>> 1. extend the AbstractLocalDataStorage and AbstractRemoteDataStorage in >>>>> storage plugin >>>>> 2. extend the model classes in model plugin >>>>> >>>>> In this way, all the abstract classes in model and storage plugins will >>>>> be initialized in the run time and perform the specified functions. >>>>> >>>>> If my understanding is correct, I will begin re-factoring work. >>>>> >>>>> Best regards >>>>> >>>>> Jun Han >>>>> >>>>> On 6/11/2011 10:32 AM, Eduard Moraru wrote: >>>>>> Hi Jun, >>>>>> >>>>>> Instead of returning Object, you should return >>>>>> org.xwiki.eclipse.core.model.Page or Object, etc. >>>>>> >>>>>> So the storage abstraction needs to include and abstract model as well in >>>>>> order to be usable. This means that the implementation also comes with a >>>>>> model implementation (xmlrpc.model.PageSummary for xmlrpc back-end, >>>>>> rest.jaxb.model.Page for rest back-end, etc.... all of them implementing >>>>>> org.xwiki.eclipse.core.model.Page) >>>>>> >>>>>> Cheers, >>>>>> Eduard >>>>>> >>>>>> On Fri, Jun 10, 2011 at 7:52 PM, Jun Han<[email protected]> wrote: >>>>>> >>>>>>> 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
