[Engine-devel] UI Plugin API improvements
René Koch (ovido)
r.koch at ovido.at
Fri Apr 5 12:16:07 UTC 2013
Sorry for my late answer - I'm quite busy at the moment.
On Sun, 2013-03-31 at 01:30 +0300, Itamar Heim wrote:
> 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.
This means for example to use %post section and patch the installed
files according to the oVirt version?
Or require min. version of oVirt in SPEC file and create multiple RPMs:
ui-plugin-1.0-1.ov32.el6.noarch.rpm => Requires: ovirt-engine >= 3.2
ui-plugin-1.0-1.ov33.el6.noarch.rpm => Requires: ovirt-engine >= 3.3
> 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.
Exactly - either make it only available if engine version is >= X or
provide a workaround if possible (depending on the importance of this
feature).
>
> so just wondering:
> - do you see uiplugins distributed as rpms or some other way?
I'll distribute my plugins in RPM and src form for download.
What I'm doing in general (not done yet for my first UI plugin, but will
follow):
- use autotools for ./configure; make; make install
./configure will allow you to set www document root and some other
settings.
- create RPM from SPEC
> - 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.
I prefer one codebase for max. 2 or 3 oVirt version and branch each
release.
e.g:
ui-plugin-1.0.x => includes code for oVirt 3.2 and oVirt 3.3
ui-plugin-1.1.x => includes code for oVirt 3.2, 3.3 and 3.4
and tag each release.
More then 3 oVirt version aren't maintainable and this doesn't make
sense as there want be bug fixes from oVirt team for these old version
(I think). But always requiring the latest oVirt version for latest UI
plugin version is also not the way I want to go, as I know that it takes
some time to upgrade to newer oVirt version...
I personally prefer to check UI API version in source code and decide
what to do over other methods like multiple RPMs or %post patch
scripts...
Regards,
René
>
> Thanks,
> Itamar
>
> >
> >
> > Thanks,
> > René
> >
> >
> >
> > -----Original message-----
> >> From:Vojtech Szocs <vszocs at redhat.com>
> >> Sent: Thursday 28th March 2013 16:25
> >> To: engine-devel <engine-devel at ovirt.org>
> >> Cc: Keith Robertson <kroberts at redhat.com>; Spenser Shumaker <sshumake at redhat.com>; Christopher Morrissey <christopher.morrissey at netapp.com>; René Koch <r.koch at ovido.at>
> >> 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
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> >
>
More information about the Devel
mailing list