It looks like there are several frameworks trying to support GWT and/or
XML/JSon serialization, but still there is a lot of work to do +
compatibility problems with the latest versions of GWT, etc.
I investigated a little bit Restlet framework, which looked promising.
The online documentation available is very limited. But good place to
look is the book 'Restlet in Action'.
Project examples:
(size: 500M)
git clone https://github.com/restlet/restlet-framework-java.git
cd restlet-framework-java/modules/org.restlet.example.book.restlet.ch09.gwt
Info from the book:
"GWT and Restlet versions
Restlet Framework version 2.0 supports version 2.0 and 2.1 of Google Web
Toolkit,
but not later, due to API breaking changes introduced in GWT 2.2.
Restlet Framework
version 2.1 supports GWT 2.3 and above, but not previous versions."
but:
"At the time of writing, the deferred binding support of Restlet only
supports the special GWT object serialization format. In future
versions, XML and JSON-based formats could be added by leveraging the
Piriti library. This library provides JSON and XML mappers for GWT based
on annotations and deferred binding. Further details are available on
Google Code at http://code.google.com/p/piriti/.";
Just DomRepresentation object and "manual" parsing is probably possible now.
Still waiting for a hope, now 'piriti'? :-)
git clone https://github.com/hpehl/piriti
Has anybody seen it in action?
On 15.2.2013 20:37, Vojtech Szocs wrote:
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.
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).
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.
Vojtech
----- Original Message -----
From: "Daniel Erez" <[email protected]>
To: "Michael Pasternak" <[email protected]>
Cc: [email protected], "Einav Cohen" <[email protected]>, [email protected], "Libor Spevak"
<[email protected]>, "Vojtech Szocs" <[email protected]>
Sent: Friday, February 15, 2013 7:17:43 PM
Subject: Re: [Engine-devel] REST API calls from the GUI
----- Original Message -----
From: "Michael Pasternak" <[email protected]>
To: "Libor Spevak" <[email protected]>
Cc: [email protected], "Daniel Erez" <[email protected]>, "Gilad Chaplik"
<[email protected]>, "Einav Cohen"
<[email protected]>, [email protected]
Sent: Wednesday, February 13, 2013 12:55:36 PM
Subject: Re: [Engine-devel] REST API calls from the GUI
Hi Libor,
This issue came across in one of the conversations i had with UX
folks, but since we didn't end
up with any conclusion/road map (nor discussed it properly to hear
other thoughts), this is a perfect
place to start this discussion,
Intuitively REST is a way to go with GWT AJAX calls
---------------------------------------------------
pros
====
- api data objects can be reused by generating java classes (using
jaxb) from the rest schema [1]
- no backend logic will be duplicated as api abstracts the backend
exposing RESTful collection/resources to operate on
- development against api is "easy" as api describes itself in RSDL
[2]
cons
====
- implementing transport layer (HTTP) under GWT
- implementing own j2xml/json/yaml/... marshalling layer
- implementing own error handling mechanism
- implementing REST callback mechanism (in GWT)
- constant maintenance of the data objects generated from the api
- painful for Java developers
Java-SDK
--------
pros
====
- abstracts transport layer (leaving developer in standard Java api)
- typesafe code (no need to mess with XML bulks)
- has own data objects to work with
- abstracts authentication/authorization
(kerberos/cookie/session/etc.)
- since SDK is auto-generated, it can be easily extended with
required
features to support UI (such as callback infrastructure for
instance)
cons
====
- has to be converted in to Javascript (not sure what the impacts are
in terms of AJAX calls/etc.)
- probably much more cons that we're not aware of and will have to
figure out with POC
thoughts?
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.
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).
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).
[1] http[s]://server[:port]/api?schema
[2] http[s]://server[:port]/api?rsdl
On 02/12/2013 06:13 PM, Libor Spevak wrote:
Hi,
I would like to ask, if there have been discussions about an option
to call REST API services directly from the Frontend (GWT layer)?
GWT compiles Java frontend-side to
Javascript, calls to backend services are performed "transparently"
by the framework using AJAX support. But, there is still a need to
have a special set of data objects
and the server-side logic can duplicate.
Java REST API SDK enables to build "thick" client. The calls are
realized using e.g. Apache HttClient and supported libraries. I
think the requirements of GWT can be a
little bit different, but something overlaps.
I found several links about REST API support from GWT, so there is
something for inspiration...
- http://www.spiffyui.org/
- http://www.zackgrossbart.com/hackito/gwt-rest/
- http://code.google.com/p/gwt-rest/
- http://restygwt.fusesource.org/
But, do you think it would be useful and what drawbacks can occur
(authentication, authorization, response times, need to support
larger set of services, painful
refactoring, ...)?
Regards,
Libor
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
