Hi Jun, On Wed, Jul 6, 2011 at 6:47 AM, Jun Han <[email protected]> wrote:
> Dear all, > > I uploaded a short demo video in youtube to show the current status of > XEclipse. > The URL is http://youtu.be/TwuNjg1XoUs > > Now the navigation panel is finished including data connection, and it > looks like: > > data connection > |- wiki > |- space > |- page, > |-- attachment > |-- comment > |-- annotation > |-- tag > |-- page class > It's looking really nice so far. Good job. You should also test it on a XEM environment with multiple wikis. Also, some minor details like providing some more consistency in the UI like: 1) Navigator elements should display (local) names everywhere (eg: 'myspace' instead of 'xwiki:myspace'), except for class names that group page objects. 2) In the element property page, you should generally display the full ID of the element ('ID' instead of 'key' in space properties), (local) name and hierarchy information (wiki for a space, space for a page, page for an object) then the other element specific metadata. 3) I would suggest that, for the page class, instead of having 'space.page' as label, you should have a generic label of 'Class'. This might be easier to locate than an ever-changing 'space.class' combination. One note about Annotations is that what you are doing right now, is relying on the AnnotationCode.AnnotationClass objects located in the page. However, the annotation feature is configurable [1], allowing it to use a different (user-specified) annotation class. Besides this level of configuration, it can also have a completely different annotation storage back-end that does not necesarily use XWiki documents to store annotation objects. For the SCRIBO project, we used a different database for storing annotations and provided an annotation storage back-end implementation to use it, so no annotation objects were located in the document itself. There currently exist some [2][3] (undocumented) extensions to the REST API that allow the addition, update and deletion of an annotation and the retrieval of the annotated rendered content plus the list of annotation IDs, but there no possiblity of getting annotation details for an annotation ID (the GET method of the REST resource needs to be implemented). Anyway, let's leave this for now as it is, since it's covering the general usecase and maybe we`ll come back later. Thanks, Eduard ---------- [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Annotations+Application#HConfigureannotations [2] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-annotations/xwiki-platform-annotation-rest/src/main/java/org/xwiki/annotation/rest/internal/AnnotationsRESTResource.java [3] https://github.com/xwiki/xwiki-platform/blob/master/xwiki-platform-core/xwiki-platform-annotations/xwiki-platform-annotation-rest/src/main/java/org/xwiki/annotation/rest/internal/SingleAnnotationRESTResource.java > > I will continue working on: > (1) re-factor xmlrpc backend > (2) modify the local storage API and apply a flat structure for the > local cached objects. > > Best regards > > Jun Han > > On 06/23/2011 05:55 AM, Eduard Moraru wrote: > > Hi Jun, > > > > On Thu, Jun 23, 2011 at 12:14 AM, Jun Han<[email protected]> wrote: > > > >> Hi Eduard, > >> > >> I think I understand what you and Fabio discussed regarding the model > >> package. > >> My current implementation looks like the following: > >> AbstractXWikiEclipsePage > >> / \ > >> RestPage XmlrpcPage > >> where RestPage wraps jaxb.model.Page and XmlrpcPage wraps > >> xmlrpc.model.Page. > >> This introduces 3 model packages, which is not appropriate. > >> > >> The suggestion from Fabio and you is to remove the redundancy and > >> various DataManager implementation will take care the model details. > > It's not the DataManager implementations that need to take care of that. > > DataManager is a final class in the org.xwiki.eclipse.storage plugin that > > uses remote or local data storages. > > > > Each storage plugin implements RemoteXWikiDataStorage, accepts and > outputs > > org.xwiki.eclipse.model entities. > > > >> For > >> example, it > > it = RestRemoteXWikiDataStorag or XmlRpcRemoteXWikiDataStorage > > > > Thanks, > > Eduard > > > >> would manipulate either jaxb.model.Page or xmlrpc.model.Page > >> and returns the XWikiEclipsePage instance. > >> > > I am on the way of re-factoring the code. > >> Best regards > >> > >> Jun Han > >> > >> On 06/22/2011 07:22 AM, Eduard Moraru wrote: > >>> 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 > >> _______________________________________________ > >> 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
