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" <[email protected]> > To: "Vojtech Szocs" <[email protected]> > Cc: "Itamar Heim" <[email protected]>, "engine-devel" <[email protected]> > 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" <[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
