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

Wed Dec 12 13:10:53 UTC 2012

Thanks Michael, in that case we can just use XML when talking with REST API.

Also, one idea worth implementing in future is to have some sort of debug console on GUI (I've seen this idea implemented in other applications). When activated, users could see REST API XML communication (request/response) between WebAdmin and Engine, which could be useful for someone interested in writing his own REST API client.

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: Wednesday, December 12, 2012 1:33:56 PM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here

On 12/12/2012 01:51 PM, Vojtech Szocs wrote:
> Hi, sorry for my late response,
> 
>>> 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?
> 
> Not sure what you mean, but here's my idea of the first iteration - what would happen on frontend side (GWT):
> 1. UiCommon, using API types, invokes query/command via RPC bridge (org.ovirt.engine.ui.frontend.Frontend class)
> 2. Frontend class, still using Generic API (GWT RPC), does the actual query/command invocation
> 3. Frontend class receives query/command result and translates it from BE type to API type (converter callback)
> 
> My idea was to isolate BE type usage into Frontend class, so that when we decide to use REST API, we just need to update our RPC bridge (Frontend class).
> 
>>> 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?
> 
> Yes, that was my original idea. I'm not against using XML when talking with REST API either. GWT supports parsing both JSON and XML.

infra. is there, but officially we not supporting json yet,
(resteasy-json-provider has issues with jaxb, - we waiting for fix)

> 
> 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: Sunday, November 25, 2012 9:27:59 AM
> Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
> 
> 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