Thanks,
Fabio
On Wed, Jun 8, 2011 at 10:26 PM, Jun Han<jun.han37(a)gmail.com> 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<jun.han37(a)gmail.com> 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<jun.han37(a)gmail.com>
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
>>>>> devs(a)xwiki.org
>>>>>
http://lists.xwiki.org/mailman/listinfo/devs
>>>>>
>>>> _______________________________________________
>>>> devs mailing list
>>>> devs(a)xwiki.org
>>>>
http://lists.xwiki.org/mailman/listinfo/devs
>>> _______________________________________________
>>> devs mailing list
>>> devs(a)xwiki.org
>>>
http://lists.xwiki.org/mailman/listinfo/devs
>>>
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>>
http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
>
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org