Hi guys,
> Are these changes already available in latest nightly repository or do I have
> to fetch them from git?
These changes are already present in oVirt git "master" branch, so if your
current work branch is based on "master", you can fetch these changes via "git
fetch && git rebase origin/master". (No need to download and apply patches
manually from git web interface, as these patches are merged already.)
> As UI API gets more and more features I was wondering if I can get the UI
> plugin API version with a JavaScript call like api.getVersion().
> I think it could sometimes be useful for UI plugin development to get the
> version of UI API to be able to use the right API call - at the moment only
> oVirt 3.2 is available which supports UI plugins, but in future there will be
> more oVirt version and hopefully RHEV will also support UI plugins (at least
> as tech preview).
> What do you think?
You're right, this is something I've been thinking about lately as well.
Since UI Plugins is oVirt feature, we can have two levels of versioning:
* level-1 = oVirt version, e.g. "3.2"
* level-2 = UI Plugin feature/API version, e.g. "1" [the number always goes up,
i.e. new oVirt release does *not* reset this number]
As Itamar mentioned below, UI plugins distributed as RPM packages can use
"level-1" version to make sure that given plugin is installed only for
supported oVirt version.
From UI plugin perspective, "level-2" version would be used to determine actual
API compliance. For example, plugin descriptor could specify supported API
version(s):
[file:/usr/share/ovirt-engine/ui-plugins/showcase.json]
{
"name": "showcase",
"apiVersion": "xxx",
"url": "/webadmin/webadmin/plugin/showcase/start.html",
"resourcePath": "showcase-files"
}
[/file]
In the example above, "apiVersion" could follow interval-like syntax, similar
to [http://maven.apache.org/enforcer/enforcer-rules/versionRanges.html]:
* "[2]" --> apiVersion == 2
* "[2,3]" --> 2 <= apiVersion <= 3
* "(2,)" --> 2 < apiVersion
Such API compliance checking could be done early on during UI plugin discovery
process, with "apiVersion" attribute being optional within the plugin
descriptor. (If not specified, the plugin meta-data & configuration would be
always sent alongside WebAdmin, just like today.)
As suggested by René, there would still be an API function to determine current
UI Plugin API version. This could be used to support situations like "plugin
supports version 2 and above [via apiVersion], but for version 3 it needs to do
something differently".
> - do you see uiplugins distributed as rpms or some other way?
We should make RPM packaging a good habit (best practice?) documented on oVirt
wiki, but IMHO oVirt version ("level-1") is not enough, we should also track
feature/API version ("level-2") separately.
Example:
* oVirt version 3.2 --> feature/API version 1
* oVirt version 3.3 --> feature/API version 2
(For RHEV, where backports are important, we could have multiple feature/API
versions within a single RHEV version.)
> - do you see uiplugin codebase trying to accomodate multiple versions,
> or branch/version similar to supported engine, and one needs latest
> engine for latest uiplugin, etc.
IIUC this can be covered with combination of "apiVersion" + runtime API like
api.getVersion().
So guys, what do you think?
Regards,
Vojtech
----- Original Message -----
From: "Itamar Heim" <[email protected]>
To: "René Koch" <[email protected]>
Cc: "Vojtech Szocs" <[email protected]>, "engine-devel" <[email protected]>
Sent: Saturday, March 30, 2013 11:30:49 PM
Subject: Re: [Engine-devel] UI Plugin API improvements
On 03/30/2013 03:12 PM, René Koch wrote:
> Hi Vojtech,
>
> Thanks a lot for the information.
> Are these changes already available in latest nightly repository or do I have
> to fetch them from git?
>
> As UI API gets more and more features I was wondering if I can get the UI
> plugin API version with a JavaScript call like api.getVersion().
> I think it could sometimes be useful for UI plugin development to get the
> version of UI API to be able to use the right API call - at the moment only
> oVirt 3.2 is available which supports UI plugins, but in future there will be
> more oVirt version and hopefully RHEV will also support UI plugins (at least
> as tech preview).
> What do you think?
interesting point. maybe less of an issue if the ui plugin is
distributed in rpm form, and can validate minimal version.
but if a single codebase for the uiplugin is to support multiple
versions for deployment, it may want to make some features available
only if engine version is X or >X.
so just wondering:
- do you see uiplugins distributed as rpms or some other way?
- do you see uiplugin codebase trying to accomodate multiple versions,
or branch/version similar to supported engine, and one needs latest
engine for latest uiplugin, etc.
Thanks,
Itamar
>
>
> Thanks,
> René
>
>
>
> -----Original message-----
>> From:Vojtech Szocs <[email protected]>
>> Sent: Thursday 28th March 2013 16:25
>> To: engine-devel <[email protected]>
>> Cc: Keith Robertson <[email protected]>; Spenser Shumaker
>> <[email protected]>; Christopher Morrissey
>> <[email protected]>; René Koch <[email protected]>
>> Subject: UI Plugin API improvements
>>
>> Hi guys,
>>
>> I've just merged some UI Plugin patches that improve existing API functions,
>> as well as add some new API functions. Please read on to learn what's new.
>>
>>
>> Modal dialog API
>> ================
>>
>> Function improved: showDialog
>>
>> New signature:
>> showDialog(title, dialogToken, contentUrl, width, height [, options])
>>
>> Example usage:
>> showDialog('My Dialog', 'my-dialog', 'http://www.foobar.com/', '800px',
>> '600px', {
>> // Default value = empty array (no buttons)
>> buttons: [
>> {
>> label: 'Do stuff',
>> onClick: function() {
>> alert('Bump!');
>> }
>> }
>> ],
>>
>> // Default value = false
>> resizeEnabled: true,
>>
>> // Default value = true
>> closeIconVisible: true,
>>
>> // Default value = true
>> closeOnEscKey: true
>> });
>>
>> Notable changes:
>> * modal dialogs now look & feel the same as standard WebAdmin dialogs
>> * width & height are strings containing CSS units
>> * the reason why buttons default to empty array is to give plugin authors
>> the choice to provide custom buttons (or similar input elements) via dialog
>> content (iframe), and use HTML5 window.postMessage to call the plugin
>> (coming soon!)
>>
>> --
>>
>> New function: setDialogContentUrl
>>
>> New signature:
>> setDialogContentUrl(dialogToken, contentUrl)
>>
>> Example usage:
>> setDialogContentUrl('my-dialog', 'http://www.example.com/')
>>
>> --
>>
>> New function: closeDialog
>>
>> New signature:
>> closeDialog(dialogToken)
>>
>> Example usage:
>> closeDialog('my-dialog')
>>
>>
>> Tab API
>> =======
>>
>> Functions improved: addMainTab & addSubTab
>>
>> New signatures:
>> addMainTab(label, historyToken, contentUrl [, options])
>> addSubTab(entityTypeName, label, historyToken, contentUrl [, options])
>>
>> Example usage:
>>
>> // Tab is left-aligned by default
>> addMainTab('Foo Tab', 'foo-tab', 'http://www.foo.com/');
>>
>> // Tab is right-aligned via options object
>> addSubTab('VirtualMachine', 'Bar Tab', 'bar-tab',
>> 'http://www.bar.com/', {
>> alignRight: true
>> });
>>
>> --
>>
>> Regards,
>> Vojtech
>>
> _______________________________________________
> Engine-devel mailing list
> [email protected]
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
[email protected]
http://lists.ovirt.org/mailman/listinfo/engine-devel
