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" <[email protected]> > To: "Vojtech Szocs" <[email protected]> > Cc: "Itamar Heim" <[email protected]>, "engine-devel" <[email protected]> > 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" <[email protected]> >>> To: "Vojtech Szocs" <[email protected]> >>> Cc: "engine-devel" <[email protected]> >>> 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 [email protected] http://lists.ovirt.org/mailman/listinfo/engine-devel
