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.cos...@netapp.com> To: "Vojtech Szocs" <vsz...@redhat.com>, "engine-devel" <engine-devel@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-boun...@ovirt.org [mailto:engine-devel-boun...@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/ _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
