6:04 a.m.
b2, write API type <-> JSON mapper, possibly using some
existing framework
Just realized that we can use GWT AutoBean framework which is part of GWT SDK itself
(it's commonly used by RequestFactory RPC mechanism):
http://code.google.com/p/google-web-toolkit/wiki/AutoBean
Vojtech
----- Original Message -----
From: "Vojtech Szocs" <vszocs(a)redhat.com>
To: "Michael Pasternak" <mpastern(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Tuesday, November 20, 2012 11:57:57 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
Hi Michael,
if we plan moving UI on top of API, you should be:
1. importing restapi-types project
2. writing intermediate layer to translate BE entities to API's using #1
3. using public entities from #2
this way your future migration to API (instead of native BE) will be much
more easier.
Indeed, this is very useful for GWT RPC -> REST API transition in general, many thanks
for pointing this out, Michael. As you suggest, we can use restapi-types mappers to
translate between internal entities and API types.
Our first iteration could be:
a1, rewrite UiCommon (UI business logic) layer to work with API types
a2, write adapter (e.g. modify Frontend class) between UiCommon using API types and
Generic API (GWT RPC) using internal entities
Our second iteration could be:
b1, remove adapter from step a2, drop Generic API (GWT RPC) usage
b2, write API type <-> JSON mapper, possibly using some existing framework
b3, write RPC layer that talks REST API with Engine
However, in order to use REST API types on client (GWT), we need their source code.
restapi-interface-definition uses Maven JAXB plugin to generate API types from XSD schema
(src/main/resources/api.xsd). On client, we need
restapi-definition-<version>-sources.jar that includes those generated API types
(target/generated-sources/xjc).
As for UI plugins (short term), we can just use restapi-types mappers and implement step
b2, (API type -> JSON mapper).
Thanks,
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Tuesday, November 20, 2012 9:48:27 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
On 11/20/2012 12:13 AM, Itamar Heim wrote:
On 11/19/2012 02:07 PM, Vojtech Szocs wrote:
> Hi Itamar,
>
> UI plugin infrastructure translates internal business entities into JSON-like
representations and passes those representations to UI plugins. (Internal entities are
NOT
> exposed to UI plugins directly.)
>
> Currently, all entities supported by UI plugin infrastructure (as per
org.ovirt.engine.ui.webadmin.plugin.entity.EntityType) are transformed into following
representation:
>
> { entityId: "[BusinessEntityGuidAsString]" }
>
> For example, a VM entity with entity ID "vm123" will translate to:
>
> { entityId: "vm123" }
>
> Translation is currently based on
org.ovirt.engine.core.common.businessentities.BusinessEntity interface, like so:
"BusinessEntity<? extends NGuid>" (we expect ID type
> parameter to be NGuid-compatible). However, I've found that there are some
entities (like Pool - org.ovirt.engine.core.common.businessentities.vm_pools) that
don't
> implement BusinessEntity interface.
ok, so we only pass the ID for now. good.
>
> Quick question to backend folks - IIRC all entities extend
org.ovirt.engine.core.common.businessentities.IVdcQueryable, but not all entities
implement
> org.ovirt.engine.core.common.businessentities.BusinessEntity interface. What is the
precise relation between IVdcQueryable and BusinessEntity?
>
> As for UI plugins, currently all entities get translated to above mentioned basic
JSON-like representation. You can see the relevant code in
> org.ovirt.engine.ui.webadmin.plugin.entity.BaseEntity.from() static method.
There's a TODO that says "make this class [BaseEntity] abstract and create
specific entity for
> each EntityType" - this means we are planning to extend the above mentioned
basic JSON-like representation for different entity types.
>
> For example, for a VM entity we might do:
>
> { entityId: "[BusinessEntityGuidAsString]", osType: "[VmOsType]"
}
just make sure the entity matches the REST API entity.
(which probably means entityId should be changed to id?)
if we plan moving UI on top of API, you should be:
1. importing restapi-types project
2. writing intermediate layer to translate BE entities to API's using #1
3. using public entities from #2
this way your future migration to API (instead of native BE) will be much
more easier.
>
> Vojtech
>
>
> ----- Original Message -----
> From: "Itamar Heim" <iheim(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)ovirt.org>
> Sent: Friday, November 16, 2012 5:24:52 PM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
>
> On 11/16/2012 06:08 PM, Vojtech Szocs wrote:
>>> is there a clear list of all APIs supported now?
>>
>> Not yet, unfortunately, this should be part of "for plugin developers"
wiki that is planned to be written in upcoming weeks.
>
> i just wanted to review how we solved not using internal entities as
> part of the API
>
--
Michael Pasternak
RedHat, ENG-Virtualization R&D
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel