Re: [xwiki-devs] [GSoC] XEclipse RESTification

23 Jun 2011

Hi Jun,

On Thu, Jun 23, 2011 at 12:14 AM, Jun Han &lt;jun.han37(a)gmail.com&gt; 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/2e5601eacba85c48b8ae6e6edf70…
  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&lt;jun.han37(a)gmail.com&gt;   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&lt;jun.han37(a)gmail.com&gt;
  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&lt;jun.han37(a)gmail.com&gt;     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&lt;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&gt;
 >>>>>>>>      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&gt;
 >>>>>>>>          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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Re: [xwiki-devs] [GSoC] XEclipse RESTification