Hi Eduard,
Thanks a lot for your advice and I will fix the UI issues.
I have already tested the multiple wikis against XEM 3.1 stable, and
will show it in the next demo.
Regarding annotations, I tried to look for a resource Url like:
/wikis/{wikiName}/spaces/{spaceName}/pages/{pageName}/annotations in
XWiki REST API, but without success. It is great to know that there is a
REST resource implementation for it. I will switch from objects to
annotation resource as soon as it comes out.
Best regards
Jun Han
On 07/06/2011 09:04 AM, Eduard Moraru wrote:
> 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
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
