8:11 a.m.
------=_Part_6244399_613158090.1352995860557
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Hi guys,
the latest revisi on of UI Plugins proof-of-c on cept patch is now available for you to
experiment with. I've split revision 7 changes apart from revision 6 to make it easier
to review new features that were added into revision 7.
You can download and apply UI Plugins patches from oVirt Gerrit code review system:
1. revision 6 - http://gerrit.ovirt.org/#/c/8120/
2. revision 7 - http://gerrit.ovirt.org/#/c/9250/
Please read on to learn what's new in this revisi on . If you have any comments,
questi on s or ideas, please let me know!
Engine REST API integration
UiInit is not the only event handler function anymore! :)
UI plugin infrastructure now integrates with Engine REST API by acquiring new REST API
session [1] upon successful user authentication.
REST API session ID is provided to plugins via RestApiSessionAcquired event handler
function. For example:
api.register({
RestApiSessionAcquired: function(sessionId) {
// Do something with newly acquired session ID
}
});
Note that UiInit function is still the first function to be invoked on the given plugin.
Plugins can therefore expect RestApiSessionAcquired function to be called shortly after
UiInit function.
For now, UI plugin infrastructure guarantees that acquired Engine REST API session will be
valid while the user stays authenticated in WebAdmin. This is done by keeping REST API
session alive via periodic heartbeats (HTTP requests) in the background. This also means
that it's safe to store and use REST API session ID until RestApiSessionAcquired
function is called again with new value. In future, we might consider dropping this kind
of guarantee to avoid the keep-alive heartbeat, and use some kind of "is session
valid" query to determine if the REST API session is still valid.
After the user signs out of WebAdmin, Engine REST API session will be closed, as per [1].
After signing in again, the process of acquiring new REST API session and calling
RestApiSessionAcquired function repeats with new session ID value.
Engine REST API integration also works seamlessly with auto login - if the user is already
logged in on the backend, running WebAdmin in new window (tab) will take him directly to
the main (authenticated) section of the application. In this case, UI plugin
infrastructure remembers the currently valid REST API session ID using HTML5 local storage
(or cookie if the browser doesn't support it).
New API function: showDialog
It's now possible to open custom dialogs using showDialog function. For example:
api.register({
UiInit: function() {
api.addMainTabActionButton('Host', 'Show Test Dialog', {
onClick: function() {
api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600, 400);
}
});
}
});
The signature of showDialog function is following:
showDialog (title, contentUrl, width, height)
For now, dialogs are shown using window.open API (non-modal browser popups ). This will be
changed in future, providing close integration with GWTP / WebAdmin dialog infrastructure.
New API function: setMainTabContentUrl
It's now possible to update content URL of the given custom main tab using
setMainTabContentUrl function. For example:
api.register({
UiInit: function() {
// Use 'about:blank' URL to display empty content
api.addMainTab('Custom Tab', 'custom-tab', 'about:blank');
},
RestApiSessionAcquired: function(sessionId) {
var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId);
api.setMainTabContentUrl('custom-tab', url);
}
});
In the above example, we first add an empty custom main tab. We do this in UiInit event
handler function because we know that it's the best place for one-time UI
initialization :) As soon as we receive REST API session ID, we update the URL of the
custom main tab. This is just an example how REST API session ID can be sent over to your
server as part of main tab content URL.
The signature of setMainTabContentUrl function is following:
setMainTabContentUrl(historyToken, contentUrl)
Note that historyToken essentially identifies the custom main tab.
That's it for now, let me know what you think!
Regards,
Vojtech
[1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement
------=_Part_6244399_613158090.1352995860557
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<html><head><style type=3D'text/css'>p { margin: 0;
}</style></head><body><=
div style=3D'font-family: times new roman,new york,times,serif; font-size: =
12pt; color: #000000'>Hi guys,<br><br>the latest revisi<span
id=3D"DWT4651"=
class=3D"ZmSearchResult"><span id=3D"DWT4655"
class=3D"ZmSearchResult">on<=
/span></span> of <span id=3D"DWT4657"
class=3D"ZmSearchResult"><span id=3D"=
DWT4661" class=3D"ZmSearchResult">UI</span></span> <span
id=3D"DWT4659" cla=
ss=3D"ZmSearchResult"><span id=3D"DWT4663"
class=3D"ZmSearchResult">Plugins=
</span></span> proof-of-c<span id=3D"DWT4653"
class=3D"ZmSearchResult"><spa=
n id=3D"DWT4665"
class=3D"ZmSearchResult">on</span></span>cept patch is now=
available for you to experiment with. I've split revision 7 changes apart =
from revision 6 to make it easier to review new features that were added in=
to revision 7.<br><br>You can download and apply UI Plugins patches from oV=
irt Gerrit code review system:<br><ol><li>revision 6 -
http://gerrit.ovirt.=
org/#/c/8120/</li><li>revision 7 -
http://gerrit.ovirt.org/#/c/9250/<br></l=
i></ol>Please read <span id=3D"DWT4669"
class=3D"ZmSearchResult"><span id=
=3D"DWT4673" class=3D"ZmSearchResult">on</span></span>
to learn what's new =
in this revisi<span id=3D"DWT4671"
class=3D"ZmSearchResult"><span id=3D"DWT=
4675" class=3D"ZmSearchResult">on</span></span>. If you have
any comments, =
questi<span id=3D"DWT4677" class=3D"ZmSearchResult"><span
id=3D"DWT4679" cl=
ass=3D"ZmSearchResult">on</span></span>s or ideas, please let me
know!<br><=
br><hr style=3D"width: 100%; height:
2px;"><br><strong>Engine REST API inte=
gration</strong><br style=3D"font-weight:
bold;"><br><em>UiInit</em> is not=
the only event handler function anymore! :)<br><br>UI plugin infrastructur=
e now integrates with Engine REST API by acquiring new REST API session [1]=
upon successful user authentication.<br><br>REST API session ID is provide=
d to plugins via <span style=3D"font-style:
italic;">RestApiSessionAcquired=
</span> event handler function. For example:<br><br><span
style=3D"font-fam=
ily: courier new,courier,monaco,monospace,sans-serif;">api.register({</span=
<br style=3D"font-family: courier
new,courier,monaco,monospace,sans-serif;=
"><span
style=3D"font-family: courier new,courier,monaco,monospace,sans-ser=
if;"> RestApiSessionAcquired: function(sessionId) {</span><br
style=
=3D"font-family: courier new,courier,monaco,monospace,sans-serif;"><span
st=
yle=3D"font-family: courier
new,courier,monaco,monospace,sans-serif;"> =
; // Do something with newly acquired session ID</span><br
styl=
e=3D"font-family: courier new,courier,monaco,monospace,sans-serif;"><span
s=
tyle=3D"font-family: courier
new,courier,monaco,monospace,sans-serif;">&nbs=
p; }</span><br style=3D"font-family: courier
new,courier,monaco,monospace,s=
ans-serif;"><span style=3D"font-family: courier
new,courier,monaco,monospac=
e,sans-serif;">});</span><br><br>Note that <span
style=3D"font-style: itali=
c;">UiInit</span> function is still the first function to be invoked on
the=
given plugin. Plugins can therefore expect <span style=3D"font-style: ital=
ic;">RestApiSessionAcquired</span> function to be called shortly after
<spa=
n style=3D"font-style: italic;">UiInit</span>
function.<br><br>For now, UI =
plugin infrastructure guarantees that acquired Engine REST API session will=
be valid while the user stays authenticated in WebAdmin. This is done by k=
eeping REST API session alive via periodic heartbeats (HTTP requests) in th=
e background. This also means that it's safe to store and use REST API sess=
ion ID until <span style=3D"font-style:
italic;">RestApiSessionAcquired</sp=
an> function is called again with new value. In future, we might consider d=
ropping this kind of guarantee to avoid the keep-alive heartbeat, and use s=
ome kind of "is session valid" query to determine if the REST API session i=
s still valid.<br><br>After the user signs out of WebAdmin, Engine REST API=
session will be closed, as per [1]. After signing in again, the process of=
acquiring new REST API session and calling <span style=3D"font-style: ital=
ic;">RestApiSessionAcquired</span> function repeats with new session ID
val=
ue.<br><br>Engine REST API integration also works seamlessly with auto logi=
n - if the user is already logged in on the backend, running WebAdmin in ne=
w window (tab) will take him directly to the main (authenticated) section o=
f the application. In this case, UI plugin infrastructure remembers the cur=
rently valid REST API session ID using HTML5 local storage (or cookie if th=
e browser doesn't support it).<br><br><hr style=3D"width: 100%;
height: 2px=
;"><br><span style=3D"font-weight: bold;">New API function:
showDialog</spa=
n><br style=3D"font-weight: bold;"><br>It's now possible to
open custom dia=
logs using <span style=3D"font-style: italic;">showDialog</span>
function. =
For example:<br><br><span style=3D"font-family: courier
new,courier,monaco,=
monospace,sans-serif;">api.register({</span><br
style=3D"font-family: couri=
er new,courier,monaco,monospace,sans-serif;"><span style=3D"font-family:
co=
urier new,courier,monaco,monospace,sans-serif;"> UiInit: function() {=
</span><br style=3D"font-family: courier
new,courier,monaco,monospace,sans-=
serif;"><span style=3D"font-family: courier
new,courier,monaco,monospace,sa=
ns-serif;">
api.addMainTabActionButton('Host', 'Show Test=
Dialog', {</span><br style=3D"font-family: courier
new,courier,monaco,mono=
space,sans-serif;"><span style=3D"font-family: courier
new,courier,monaco,m=
onospace,sans-serif;"> onClick:
function() {<=
/span><br style=3D"font-family: courier new,courier,monaco,monospace,sans-s=
erif;"><span style=3D"font-family: courier
new,courier,monaco,monospace,san=
s-serif;">
api.showDialog('Test D=
ialog', 'http://www.ovirt.org/', 600,
400);<br> &nbs=
p; }</span><br style=3D"font-family: courier
new,courier,monaco,monospace,s=
ans-serif;"><span style=3D"font-family: courier
new,courier,monaco,monospac=
e,sans-serif;"> });</span><br
style=3D"font-family: couri=
er new,courier,monaco,monospace,sans-serif;"><span style=3D"font-family:
co=
urier new,courier,monaco,monospace,sans-serif;"> }</span><br
style=3D=
"font-family: courier new,courier,monaco,monospace,sans-serif;"><span
style=
=3D"font-family: courier
new,courier,monaco,monospace,sans-serif;">});</spa=
n><br style=3D"font-family: courier new,courier,monaco,monospace,sans-serif=
;"><br>The signature of <span style=3D"font-style:
italic;">showDialog</spa=
n> function is following:<br><br><div style=3D"margin-left:
40px;"><span st=
yle=3D"font-style: italic;">showDialog(title, contentUrl, width,
height)</s=
pan><br></div><br>For now, dialogs are shown using <span
style=3D"font-styl=
e: italic;">window.open</span> API (non-modal browser popups). This will
be=
changed in future, providing close integration with GWTP / WebAdmin dialog=
infrastructure.<br><br><hr style=3D"width: 100%; height:
2px;"><br><span s=
tyle=3D"font-weight: bold;">New API function:
setMainTabContentUrl</span><b=
r style=3D"font-weight: bold;"><br>It's now possible to update
content URL =
of the given custom main tab using <span style=3D"font-style:
italic;">setM=
ainTabContentUrl</span> function. For example:<br><br><span
style=3D"font-f=
amily: courier new,courier,monaco,monospace,sans-serif;">api.register({</sp=
an><br style=3D"font-family: courier new,courier,monaco,monospace,sans-seri=
f;"><span style=3D"font-family: courier
new,courier,monaco,monospace,sans-s=
erif;"> UiInit: function() {</span><br
style=3D"font-family: courier =
new,courier,monaco,monospace,sans-serif;"><span style=3D"font-family:
couri=
er new,courier,monaco,monospace,sans-serif;"> // Use
'abo=
ut:blank' URL to display empty content</span><br style=3D"font-family:
cour=
ier new,courier,monaco,monospace,sans-serif;"><span style=3D"font-family:
c=
ourier new,courier,monaco,monospace,sans-serif;">
api.add=
MainTab('Custom Tab', 'custom-tab',
'about:blank');</span><br style=3D"font=
-family: courier new,courier,monaco,monospace,sans-serif;"><span
style=3D"f=
ont-family: courier new,courier,monaco,monospace,sans-serif;">
},</sp=
an><br style=3D"font-family: courier new,courier,monaco,monospace,sans-seri=
f;"><span style=3D"font-family: courier
new,courier,monaco,monospace,sans-s=
erif;"> RestApiSessionAcquired: function(sessionId) {</span><br
style=
=3D"font-family: courier new,courier,monaco,monospace,sans-serif;"><span
st=
yle=3D"font-family: courier
new,courier,monaco,monospace,sans-serif;"> =
; var url =3D 'http://www.ovirt.org/?s=3D' +
encodeURIComponent=
(sessionId);</span><br style=3D"font-family: courier
new,courier,monaco,mon=
ospace,sans-serif;"><span style=3D"font-family: courier
new,courier,monaco,=
monospace,sans-serif;">
api.setMainTabContentUrl('custom-=
tab', url);</span><br style=3D"font-family: courier
new,courier,monaco,mono=
space,sans-serif;"><span style=3D"font-family: courier
new,courier,monaco,m=
onospace,sans-serif;"> }</span><br style=3D"font-family:
courier new,=
courier,monaco,monospace,sans-serif;"><span style=3D"font-family: courier
n=
ew,courier,monaco,monospace,sans-serif;">});</span><br
style=3D"font-family=
: courier new,courier,monaco,monospace,sans-serif;"><br>In the above
exampl=
e, we first add an empty custom main tab. We do this in <span style=3D"font=
-style: italic;">UiInit</span> event handler function because we know that
=
it's the best place for one-time UI initialization :) As soon as we receive=
REST API session ID, we update the URL of the custom main tab. This is jus=
t an example how REST API session ID can be sent over to your server as par=
t of main tab content URL.<br><br>The signature of <span
style=3D"font-styl=
e: italic;">setMainTabContentUrl</span> function is
following:<br><br><div =
style=3D"margin-left: 40px;"><span style=3D"font-style:
italic;">setMainTab=
ContentUrl(historyToken, contentUrl)</span><br></div><br>Note that
<span st=
yle=3D"font-style: italic;">historyToken</span> essentially identifies
the =
custom main tab.<br><br><hr style=3D"width: 100%; height:
2px;"><br>That's =
it for now, let me know what you
think!<br><br>Regards,<br>Vojtech<br><br><=
span style=3D"font-weight: bold;"></span><br>[1]
http://wiki.ovirt.org/wiki=
/Features/RESTSessionManagement<br><br></div></body></html>
------=_Part_6244399_613158090.1352995860557--
7:33 a.m.
On 11/15/2012 06:11 PM, Vojtech Szocs wrote:
Hi guys,
the latest revision of UI Plugins proof-of-concept patch is now
available for you to experiment with. I've split revision 7 changes
apart from revision 6 to make it easier to review new features that were
added into revision 7.
You can download and apply UI Plugins patches from oVirt Gerrit code
review system:
1. revision 6 - http://gerrit.ovirt.org/#/c/8120/
2. revision 7 - http://gerrit.ovirt.org/#/c/9250/
Please read on to learn what's new in this revision. If you have any
comments, questions or ideas, please let me know!
------------------------------------------------------------------------
*Engine REST API integration*
/UiInit/ is not the only event handler function anymore! :)
UI plugin infrastructure now integrates with Engine REST API by
acquiring new REST API session [1] upon successful user authentication.
REST API session ID is provided to plugins via RestApiSessionAcquired
event handler function. For example:
api.register({
RestApiSessionAcquired: function(sessionId) {
// Do something with newly acquired session ID
}
});
Note that UiInit function is still the first function to be invoked on
the given plugin. Plugins can therefore expect RestApiSessionAcquired
function to be called shortly after UiInit function.
For now, UI plugin infrastructure guarantees that acquired Engine REST
API session will be valid while the user stays authenticated in
WebAdmin. This is done by keeping REST API session alive via periodic
heartbeats (HTTP requests) in the background. This also means that it's
safe to store and use REST API session ID until RestApiSessionAcquired
function is called again with new value. In future, we might consider
dropping this kind of guarantee to avoid the keep-alive heartbeat, and
use some kind of "is session valid" query to determine if the REST API
session is still valid.
After the user signs out of WebAdmin, Engine REST API session will be
closed, as per [1]. After signing in again, the process of acquiring new
REST API session and calling RestApiSessionAcquired function repeats
with new session ID value.
Engine REST API integration also works seamlessly with auto login - if
the user is already logged in on the backend, running WebAdmin in new
window (tab) will take him directly to the main (authenticated) section
of the application. In this case, UI plugin infrastructure remembers the
currently valid REST API session ID using HTML5 local storage (or cookie
if the browser doesn't support it).
------------------------------------------------------------------------
New API function: showDialog
It's now possible to open custom dialogs using showDialog function. For
example:
api.register({
UiInit: function() {
api.addMainTabActionButton('Host', 'Show Test Dialog', {
onClick: function() {
api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600,
400);
}
});
}
});
The signature of showDialog function is following:
showDialog(title, contentUrl, width, height)
For now, dialogs are shown using window.open API (non-modal browser
popups). This will be changed in future, providing close integration
with GWTP / WebAdmin dialog infrastructure.
------------------------------------------------------------------------
New API function: setMainTabContentUrl
It's now possible to update content URL of the given custom main tab
using setMainTabContentUrl function. For example:
api.register({
UiInit: function() {
// Use 'about:blank' URL to display empty content
api.addMainTab('Custom Tab', 'custom-tab', 'about:blank');
},
RestApiSessionAcquired: function(sessionId) {
var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId);
api.setMainTabContentUrl('custom-tab', url);
}
});
In the above example, we first add an empty custom main tab. We do this
in UiInit event handler function because we know that it's the best
place for one-time UI initialization :) As soon as we receive REST API
session ID, we update the URL of the custom main tab. This is just an
example how REST API session ID can be sent over to your server as part
of main tab content URL.
The signature of setMainTabContentUrl function is following:
setMainTabContentUrl(historyToken, contentUrl)
Note that historyToken essentially identifies the custom main tab.
------------------------------------------------------------------------
That's it for now, let me know what you think!
Regards,
Vojtech
[1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
is there a clear list of all APIs supported now?
8:08 a.m.
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.
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Friday, November 16, 2012 4:33:23 PM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
On 11/15/2012 06:11 PM, Vojtech Szocs wrote:
Hi guys,
the latest revision of UI Plugins proof-of-concept patch is now
available for you to experiment with. I've split revision 7 changes
apart from revision 6 to make it easier to review new features that were
added into revision 7.
You can download and apply UI Plugins patches from oVirt Gerrit code
review system:
1. revision 6 - http://gerrit.ovirt.org/#/c/8120/
2. revision 7 - http://gerrit.ovirt.org/#/c/9250/
Please read on to learn what's new in this revision. If you have any
comments, questions or ideas, please let me know!
------------------------------------------------------------------------
*Engine REST API integration*
/UiInit/ is not the only event handler function anymore! :)
UI plugin infrastructure now integrates with Engine REST API by
acquiring new REST API session [1] upon successful user authentication.
REST API session ID is provided to plugins via RestApiSessionAcquired
event handler function. For example:
api.register({
RestApiSessionAcquired: function(sessionId) {
// Do something with newly acquired session ID
}
});
Note that UiInit function is still the first function to be invoked on
the given plugin. Plugins can therefore expect RestApiSessionAcquired
function to be called shortly after UiInit function.
For now, UI plugin infrastructure guarantees that acquired Engine REST
API session will be valid while the user stays authenticated in
WebAdmin. This is done by keeping REST API session alive via periodic
heartbeats (HTTP requests) in the background. This also means that it's
safe to store and use REST API session ID until RestApiSessionAcquired
function is called again with new value. In future, we might consider
dropping this kind of guarantee to avoid the keep-alive heartbeat, and
use some kind of "is session valid" query to determine if the REST API
session is still valid.
After the user signs out of WebAdmin, Engine REST API session will be
closed, as per [1]. After signing in again, the process of acquiring new
REST API session and calling RestApiSessionAcquired function repeats
with new session ID value.
Engine REST API integration also works seamlessly with auto login - if
the user is already logged in on the backend, running WebAdmin in new
window (tab) will take him directly to the main (authenticated) section
of the application. In this case, UI plugin infrastructure remembers the
currently valid REST API session ID using HTML5 local storage (or cookie
if the browser doesn't support it).
------------------------------------------------------------------------
New API function: showDialog
It's now possible to open custom dialogs using showDialog function. For
example:
api.register({
UiInit: function() {
api.addMainTabActionButton('Host', 'Show Test Dialog', {
onClick: function() {
api.showDialog('Test Dialog', 'http://www.ovirt.org/', 600,
400);
}
});
}
});
The signature of showDialog function is following:
showDialog(title, contentUrl, width, height)
For now, dialogs are shown using window.open API (non-modal browser
popups). This will be changed in future, providing close integration
with GWTP / WebAdmin dialog infrastructure.
------------------------------------------------------------------------
New API function: setMainTabContentUrl
It's now possible to update content URL of the given custom main tab
using setMainTabContentUrl function. For example:
api.register({
UiInit: function() {
// Use 'about:blank' URL to display empty content
api.addMainTab('Custom Tab', 'custom-tab', 'about:blank');
},
RestApiSessionAcquired: function(sessionId) {
var url = 'http://www.ovirt.org/?s=' + encodeURIComponent(sessionId);
api.setMainTabContentUrl('custom-tab', url);
}
});
In the above example, we first add an empty custom main tab. We do this
in UiInit event handler function because we know that it's the best
place for one-time UI initialization :) As soon as we receive REST API
session ID, we update the URL of the custom main tab. This is just an
example how REST API session ID can be sent over to your server as part
of main tab content URL.
The signature of setMainTabContentUrl function is following:
setMainTabContentUrl(historyToken, contentUrl)
Note that historyToken essentially identifies the custom main tab.
------------------------------------------------------------------------
That's it for now, let me know what you think!
Regards,
Vojtech
[1] http://wiki.ovirt.org/wiki/Features/RESTSessionManagement
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
is there a clear list of all APIs supported now?
8:24 a.m.
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
4:07 a.m.
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.
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]" }
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)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
2:13 p.m.
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?)
Vojtech
----- Original Message -----
From: "Itamar Heim" <iheim(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)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
12:48 a.m.
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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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
2:57 a.m.
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
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
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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
3:04 a.m.
b2, write API type <-> JSON mapper, possibly using some
existing framework
Just realized that we can use GWT AutoBean framework which is part of GWT SDK itself
(it's commonly used by RequestFactory RPC mechanism):
http://code.google.com/p/google-web-toolkit/wiki/AutoBean
Vojtech
----- Original Message -----
From: "Vojtech Szocs" <vszocs(a)redhat.com>
To: "Michael Pasternak" <mpastern(a)redhat.com>
Cc: "engine-devel" <engine-devel(a)ovirt.org>
Sent: Tuesday, November 20, 2012 11:57:57 AM
Subject: Re: [Engine-devel] UI Plugins: PoC patch revision 7 is here
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
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
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "engine-devel" <engine-devel(a)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
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
12:27 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)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
3:51 a.m.
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.
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "engine-devel" <engine-devel(a)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
4:33 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)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
5:10 a.m.
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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>>> Cc: "engine-devel" <engine-devel(a)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
5:18 a.m.
On 12/12/2012 03:10 PM, Vojtech Szocs wrote:
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.
right, i always do that in all clients i've wrote (including SDKs & CLI).
Vojtech
----- Original Message -----
From: "Michael Pasternak" <mpastern(a)redhat.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>
Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
> To: "Vojtech Szocs" <vszocs(a)redhat.com>
> Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>> Cc: "Itamar Heim" <iheim(a)redhat.com>, "engine-devel"
<engine-devel(a)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(a)redhat.com>
>>>> To: "Vojtech Szocs" <vszocs(a)redhat.com>
>>>> Cc: "engine-devel" <engine-devel(a)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
4153
days inactive
4180
days old
13 comments
3 participants
participants (3)
-
Itamar Heim -
Michael Pasternak -
Vojtech Szocs