8:12 a.m.
Hi George,
the PoC defines a simple ActionButtonClick event which is fired when the user clicks on
"New Server" button, and WebAdmin invokes ActionButtonClick function on all
plugins. This is just an example to demonstrate how plugin invocation could work.
If you want to add new button to VM main tab, there should be a separate event fired when
the VM main tab is rendered, with plugins providing extra button definitions.
Alternatively, pluginApi object can provide some API to add these buttons at time when
plugin code gets loaded. Unfortunately, this isn't part of the PoC yet, as I wanted to
discuss this with you before continuing with PoC implementation.
As for developing plugins with GWT, I've sent a mail about this, discussing two
possible ways to develop plugins. We should evaluate pros/cons of each approach and decide
which way to go first.. (the PoC contains hand-written JavaScript for now though)
Vojtech
----- Original Message -----
From: "George Costea" <George.Costea(a)netapp.com>
To: "Vojtech Szocs" <vszocs(a)redhat.com>, "engine-devel"
<engine-devel(a)ovirt.org>
Sent: Wednesday, July 25, 2012 5:25:17 PM
Subject: RE: [Engine-devel] oVirt UI Plugins: Update on current progress
Hi Vojtech,
I just had a chance to try the patch today and it works great. When I click the “New
Server” button on the “Virtual Machines” tab I see the alert. What do I do to add a new
button beside of the “New Server” button or at the end after the “Guide Me” button? I
would like to add my own button there and then invoke my own UI built with GWT.
Thanks,
George
From: engine-devel-bounces(a)ovirt.org [mailto:engine-devel-bounces@ovirt.org] On Behalf Of
Vojtech Szocs
Sent: Friday, July 20, 2012 4:38 PM
To: engine-devel
Subject: [Engine-devel] oVirt UI Plugins: Update on current progress
Hi guys,
I've spent some time working on UI Plugins proof-of-concept (PoC) implementation, and
thought I'd share my results with you. I've attached a patch that reflects the
current progress.
The actual PoC implementation takes some inspiration from oVirt UI Plugins wiki page, and
simplifies/streamlines/improves its main concepts. The goal is to have simple-to-use, yet
flexible and robust plugin infrastructure. Major changes to the original design are
outlined below.
Each UI plugin runs within the context of an iframe, and therefore requires a plugin
source page that executes the actual plugin code.
* iframe is essentially the sandbox for each plugin. We can disable plugins by
detaching their iframe elements from the main document during WebAdmin runtime. This also
allows us to implement features such as plugin safe mode (no plugins loaded on WebAdmin
startup).
* Plugin source pages and WebAdmin host page share the same origin (protocol, domain,
port), with plugin source pages being served through EngineManager application server
(JBoss AS). This is to avoid cross-domain window/iframe communication issues, when the
actual plugin code running in an iframe tries to register itself into WebAdmin main
document's pluginApi object.
* There's a servlet designed to render plugin source page for all plugins (
PluginSourcePageServlet ). For the given plugin, it detects its dependencies (3rd party
JavaScript libraries) and configuration object (JSON data), reads the actual plugin code,
and assembles everything into the resulting HTML page (to be evaluated by the plugin
iframe).
* iframe isolates plugin dependencies (3rd party JavaScript libraries) from other
plugins and the main WebAdmin document. In practice, this means that plugin A can use
jQuery 1.7 and plugin B can use jQuery 1.6 without the fear of any clashes.
* Last but not least, writing plugins in Google Web Toolkit (GWT) should be as easy as
providing your own plugin source page. Just deploy your GWT plugin application on JBoss AS
(next to engine.ear ), and point to GWT plugin application host page.
The current PoC declares a simple plugin that gets loaded using hard-coded values in
PluginSourcePageServlet . Actual plugin code registers the plugin into global
pluginApi.plugins object, with one sample event handler function ( ActionButtonClick ).
Just after that, the plugin reports in as ready by calling pluginApi.ready function. This
essentially puts the plugin into use within WebAdmin.
To simulate extension point (application event to be consumed by plugins), when the user
clicks "New server" button on "Virtual Machines" main tab,
ActionButtonClickEvent gets fired through WebAdmin event bus. PluginEventHandler receives
this event and invokes ActionButtonClick event handler function on all plugins.
(Note: for passing context objects from WebAdmin to plugin event handler functions,
I'm planning to experiment with gwt-exporter project [1]. This would greatly simplify
the way how WebAdmin exposes context-specific plugin API to event handler functions.)
As for the next step, I suggest to have some meeting (conference) to discuss the PoC in
detail, and outline tasks for the near future. Also, please let me know what you think of
the PoC so far.
Cheers,
Vojtech
[1] http://code.google.com/p/gwt-exporter/