[Engine-devel] UI Plugins: PoC patch revision 7 is here

[Michael Pasternak]

On 11/20/2012 12:57 PM, Vojtech Szocs wrote:
> 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

does this mean converting three times?

> 
> 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

do you mean talking with api in JSON?

> 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 at redhat.com>
> To: "Vojtech Szocs" <vszocs at redhat.com>
> Cc: "Itamar Heim" <iheim at redhat.com>, "engine-devel" <engine-devel at 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 at redhat.com>
>>> To: "Vojtech Szocs" <vszocs at redhat.com>
>>> Cc: "engine-devel" <engine-devel at 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