[Engine-devel] oVirt UI Plugins: Update on current progress

[Vojtech Szocs]

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/ 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20120720/11b56795/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: WIP-UI-Plugins-PoC.patch
Type: text/x-patch
Size: 18528 bytes
Desc: not available
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20120720/11b56795/attachment-0002.bin>