[Engine-devel] UI plugins - next steps

[Vojtech Szocs]

Hi Itamar,

> I think its time we revisit the implications/scope of moving the UI to 
> work on top of the REST API or just the REST entities.
> until then, i think just adding specific fields that make sense/are 
> asked for for these entities should be good enough.

Sounds reasonable, given that we want to move UI on top of REST API anyway.

> if we see the "moving UI on top of REST API" is still too far, then 
> doing the type mapping for just the plugins would make sense.

Maybe the "moving UI on top of REST API" process could be split into two phases:

1) patching UiCommon code to work with generated REST API types, instead of internal business entities
   patching Frontend RPC bridge (still using Generic API) to map internal business entities to REST API types

2) patching Frontend RPC bridge to map action/query invocation to REST API HTTP requests
   patching Frontend RPC bridge to map REST API HTTP responses back to REST API types

Doing both 1) and 2) in one sweep might be risky..

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: Thursday, December 13, 2012 12:39:38 AM
Subject: Re: [Engine-devel] UI plugins - next steps

On 12/12/2012 02:57 PM, Vojtech Szocs wrote:
> 1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects
>     - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB)
>     - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves)

I think its time we revisit the implications/scope of moving the UI to 
work on top of the REST API or just the REST entities.
until then, i think just adding specific fields that make sense/are 
asked for for these entities should be good enough.
if we see the "moving UI on top of REST API" is still too far, then 
doing the type mapping for just the plugins would make sense.