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 >>>>>>>>> _______________________________________________ >>>>>>>>> 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
