Hi guys,
>> > > We can't directly use the restapi models in the
client side, as
>> > > they have lot of xml and annotations stuff involved which will not
>> > > be compatible with GWT.
> >
> > why? they only have jaxb annotations which are 'must' for
> > serialization & talking with api.
Actually, we *can* use JAXB-generated REST API Java types with GWT, since GWT compiler
simply ignores annotations in Java sources during compilation to JavaScript.
The only problem I see is REST API Java types using stuff like
javax.xml.datatype.XMLGregorianCalendar - we'd have to emulate it in GWT
(shouldn't be an issue).
Other than that, I'd recommend using JAXB-generated REST API Java types, as they
always match current REST API schema (api.xsd).
As for the marshalling layer, we can't use JAXB (REST API Java SDK) with GWT, but we
can still write deferred binding generator to generate mappers for XML <--> Rest API
Java type conversion.
if you not using JAXB, you should make sure calling variables in the
classes that will be marshalled to XML
as they are defined in the api schema and not using Java naming convention (as XJC does),
Yeah, with XML representation we would have to do this ourselves.
On the other hand, things would be much simpler if REST API supported JSON, which is
something we should consider (wait for JSON support? work with XML?)
>> > > It would be better if We can come up with a
"GWT REST API SDK",
>> > > which is analogous Java SDK.
I'd rather have JavaScript REST API SDK which we could use with GWT, this would open
up new possibilities for web clients.
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Kanagaraj Mayilsamy" <kmayilsa(a)redhat.com>
Cc: "Vojtech Szocs" <vszocs(a)redhat.com>, engine-devel(a)ovirt.org,
arch(a)ovirt.org
Sent: Wednesday, February 20, 2013 2:07:15 PM
Subject: Re: [Engine-devel] REST API calls from the GUI
On 02/20/2013 02:45 PM, Kanagaraj Mayilsamy wrote:
>
> ----- Original Message -----
>> > From: "Michael Pasternak" <mpastern(a)redhat.com>
>> > To: "Kanagaraj Mayilsamy" <kmayilsa(a)redhat.com>
>> > Cc: "Vojtech Szocs" <vszocs(a)redhat.com>,
engine-devel(a)ovirt.org, arch(a)ovirt.org
>> > Sent: Wednesday, February 20, 2013 5:55:50 PM
>> > Subject: Re: [Engine-devel] REST API calls from the GUI
>> >
>> > On 02/18/2013 05:09 AM, Kanagaraj Mayilsamy wrote:
>>> > >
>>> > >
>>> > > ----- Original Message -----
>>>> > >> From: "Vojtech Szocs" <vszocs(a)redhat.com>
>>>> > >> To: "Daniel Erez" <derez(a)redhat.com>
>>>> > >> Cc: arch(a)ovirt.org, engine-devel(a)ovirt.org
>>>> > >> Sent: Saturday, February 16, 2013 1:07:56 AM
>>>> > >> Subject: Re: [Engine-devel] REST API calls from the GUI
>>>> > >>
>>>> > >> Hi Daniel,
>>>> > >>
>>>>> > >>> The first alternative can be implemented by using
GWT
>>>>> > >>> RequestBuilder (for sending the HTTP requests)
>>>>> > >>> and GWT overlay types (that can be generated from
java POJOs).
>>>>> > >>> Probably best performance-wise/less data type
conversions/etc;
>>>>> > >>> However, basically means writing a JavaScript SDK.
>>>> > >>
>>>> > >> Yes, we can use RequestBuilder for making AJAX HTTP
requests, but
>>>> > >> using GWT overlay types is possible only if REST API fully
>>>> > >> supports
>>>> > >> JSON format. In case of XML format, we would have to use
GWT
>>>> > >> XMLParser to map "restapi-types"
entities/collections to/from XML
>>>> > >> strings, e.g. we could write GWT deferred binding
generators to
>>>> > >> generate such mappers from current schema.
>>> > >
>>> > >
AutoBean(http://code.google.com/p/google-web-toolkit/wiki/AutoBean)
>>> > > could be useful instead of generating/writing overlay types.
>>> > > AutoBeans will be converted overlay types internally by GWT
>>> > > automatically.
>>> > >
>>>> > >>
>>>>> > >>> The benefit of the second alternative is currently
rather vague
>>>>> > >>> since the Java SDK can't be converted to
JavaScript as is
>>>>> > >>> (can't use apache.commons and javax packages in
GWT client side).
>>>>> > >>> Need to check how easily they can be replaced
>>>>> > >>> with JRE libraries that GWT can emulate (for
supporting both GWT
>>>>> > >>> web and debug mode).
>>>> > >>
>>>> > >> Indeed, we can't use Java REST API SDK as it is with
GWT:
>>>> > >>
https://developers.google.com/web-toolkit/doc/latest/RefJreEmulation
>>>> > >>
>>>> > >> This means we need to implement our own transport layer
>>>> > >> (RequestBuilder) and most likely also the marshalling
layer
>>>> > >> (XMLParser vs. JSONParser vs. overlay types).
>>> > >
>> > > It would be better if We can come up with a
"GWT REST API SDK",
>> > > which is analogous Java SDK.
>>> > >
>>>> > >>
>>>>> > >>> A third alternative could be simply maintaining the
current GWT
>>>>> > >>> RPC
>>>>> > >>> mechanism we use.
>>>>> > >>> I.e. integrating the Java SDK into the GWT servlet,
which means
>>>>> > >>> wrapping the API into GenericApiGWTService.
>>>>> > >>> The main drawback is an additional layer of data
type conversion
>>>>> > >>> and round-trip:
>>>>> > >>> Backend <-> REST <-> Java SDK (servlet)
<-> JavaScript (client).
>>>> > >>
>>>> > >> This is interesting, generic API could be used to transfer
>>>> > >> "restapi-types", along with extra information to
emulate proper
>>>> > >> HTTP
>>>> > >> request, without any marshalling involved.
>>>> > >>
>>> > >
>> > > We can't directly use the restapi models in the
client side, as
>> > > they have lot of xml and annotations stuff involved which will not
>> > > be compatible with GWT.
> >
> > why? they only have jaxb annotations which are 'must' for
> > serialization & talking with api.
>> >
> We can't use jaxb, as GWT won't emulate the jaxb classes.
https://developers.google.com/web-toolkit/doc/1.6/RefJreEmulation
>
> If at all we want use jaxb, we should include the source of jaxb to ui module, so
that GWT can compile them to javascript equivalents. But this is less likely as jaxb
relies heavily on reflection which not supported by GWT.
>
if you not using JAXB, you should make sure calling variables in the classes that will be
marshalled to XML
as they are defined in the api schema and not using Java naming convention (as XJC does),
if your schema->java converting tool support this, you're okay.
--
Michael Pasternak
RedHat, ENG-Virtualization R&D