[Users] Community feedback on the new UI-plugin Framework

[Vojtech Szocs]

Hi Oved, replying late, thanks for sharing the feedback!

> 1. People liked the fact that it is a simple framework, allowing you to do nice extensions rapidly,  without the need to know complex technologies (simple javascript knowledge is all you need to know).

Glad to hear this! In fact, a minimalistic UI plugin is just one JSON file (plugin descriptor) + one HTML file (plugin host page): http://www.ovirt.org/Features/UIPlugins#UI_plugin_cheat_sheet

> 2. People want the framework to provide tools for adding UI components (main/sub tabs, dialogs, etc.) that aren't URL based, but are based on components we currently have in oVirt, such as grids, key-value pairs (such as the general sub-tab), action buttons in these custom tabs and etc.

Yes, this is planned long-term, e.g. we can have an API for creating table-based main/sub tab, with functions that allow adding columns, setting data or adding custom action buttons.

On the other hand, I'm also planning to prototype another approach for providing custom UI content - using popular JavaScript frameworks like Backbone/Underscore/jQuery to construct UI on the client (via plugin code) instead of using contentURL/iframe approach. (I'll post a separate email on this later on.)

> 4. Plugin management
> * The ability to see what plugins are installed... install new plugins and remove existing ones.

Actually we plan to have WebAdmin dialog that lists loaded plugins, with the option to enable/disable them or view their current status.

As for installing/removing plugins, this requires root privileges since plugins are meant to be installed/removed as RPM packages. Not sure if a separate tool for this is necessary.

> * Change the plugin configuration through webadmin
> * Distinguish between public plugin configuration entries (entries the user to change), to private ones (entries it can't).

Very interesting ideas! Public configuration entries could be changed via <plugin>-config.json or in WebAdmin, private ones would be hidden/read-only.

Regards,
Vojtech


----- Original Message -----
From: "Oved Ourfalli" <ovedo at redhat.com>
To: "ovirt-users" <users at ovirt.org>
Cc: "Christopher Morrissey" <christopher.morrissey at netapp.com>, "Vojtech Szocs" <vszocs at redhat.com>
Sent: Friday, January 25, 2013 2:41:40 AM
Subject: Community feedback on the new UI-plugin Framework

Hey all,

We had an oVirt workshop this week, which included a few sessions about the new oVirt UI Plugin framework, including a Hackaton and a BOF session.

I've gathered some feedback we got from the different participants about the framework, and what they would like to see in the future of it.

1. People liked the fact that it is a simple framework, allowing you to do nice extensions rapidly,  without the need to know complex technologies (simple javascript knowledge is all you need to know).

2. People want the framework to provide tools for adding UI components (main/sub tabs, dialogs, etc.) that aren't URL based, but are based on components we currently have in oVirt, such as grids, key-value pairs (such as the general sub-tab), action buttons in these custom tabs and etc.

The main reason for that is to easily develop a plugin with an oVirt-like look-and-feel. Chris Morrissey from Netapp showed a very nice plugin he wrote that did have an oVirt-like look-and-feel, but it wasn't easy.... and it required him to to develop something specific for the plugin to interact with, in the 3rd party application (something similar to the work we did in the oVirt-Foreman UI-plugin).

3. Support adding tasks to the system - plugins may trigger asynchronous tasks behind the scene, both oVirt and external ones. oVirt tasks and their progress will be reflected in the tasks management view, but if the flows contain external tasks as well, then it would be hard to track through the oVirt UI.

4. Plugin management
* The ability to see what plugins are installed... install new plugins and remove existing ones.
* Change the plugin configuration through webadmin
* Distinguish between public plugin configuration entries (entries the user to change), to private ones (entries it can't).

I guess that this point will be relevant for engine-plugins as well (once support for such plugins will be available) so we should consider providing a similar solution for both. Also, Chris pointed out that it should be taken into consideration as well when working on supporting HA-oVirt-engine, as plugins are vital part of the oVirt environment.

If you find the feedback above true, or you have other comments that weren't mentioned here, please share it with us!

Thank you,
Oved

P.S:
I guess the slides will be uploaded sometime next week (I guess someone would have asked it soon... so now you have your answer :-) )