Hi Jun, I`m pinging you since I don`t know if you were following the little discussion on https://github.com/junhan/xwiki-eclipse/commit/2e5601eacba85c48b8ae6e6edf70b18fb3715f0d#commitcomment-440786 based on Fabio's suggestions.
Out of all the aspects, I think this is the one you should focus on now and finish the refactoring so you can proceed with the REST specifics. Cheers, Eduard On 06/20/2011 08:10 PM, Fabio Mancinelli wrote: > 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 _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
