<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'>Hello everyone,<br><br>it's been a while since I posted an update on UI Plugins so I thought I'd share some updates and plans for near future.<br><br>First of all, I apologize to Chris and other NetApp folks for not being able to attend oVirt Workshop in Sunnyvale. I've caught a terrible flu just one day before flying to the conference, which is most unfortunate :( I've attached both presentations I prepared for the workshop to this email for reference. Once again, sorry for my absence at the workshop.<br><br>The UI Plugins feature wiki [http://www.ovirt.org/Features/UIPlugins] has been updated in the mean time, you can check it out and let me know what you think. There are still some TODOs like documenting supported functions/events, I'll take care of this in the upcoming days.<br><br>I'm currently working on improving showDialog API, moving away from native browser popups and using WebAdmin dialog infrastructure. You can find the first (work-in-progress) version of the patch at [http://gerrit.ovirt.org/#/c/11717/]. Besides showDialog API, roadmap for near future is following:<br><ul><li>allow adding action buttons (<em>api.addMainTabActionButton</em>) to main tabs that are currently not supported<span style="white-space:pre"></span></li><ul><li>currently supported main tabs: Cluster, DataCenter, Disk, Host, Storage, Template, VirtualMachine</li><li>remaining main tabs to support: Event, Network, Pool, Quota, User, Volume<br></li></ul></ul><ul><li>improve addMainTabActionButton API to allow different action button representations<br></li><ul><li>add both context-sensitive button (toolbar) and corresponding context-menu item (menu)<br></li><li>add only context-sensitive button (toolbar)</li><li>add only context-menu item (menu)</li></ul></ul><ul><li>improve addMainTab/addSubTab API to allow tab widget alignment (left or right)</li><ul><li>initial patch submitted by Spenser Shumaker [http://gerrit.ovirt.org/#/c/11273/]<br></li></ul></ul>I've been also thinking about UI Plugins infrastructure and development in general, and came up with some ideas I'm planning to try out:<br><ul><li>invert control with regard to obtaining <span style="font-style: italic;">pluginApi</span> instance<br></li><ul><li>currently, WebAdmin exposes pluginApi object in top-level context, and plugins obtain pluginApi via parent.pluginApi(pluginName)</li><li>in future, WebAdmin will evaluate pluginApi(pluginName) within top-level context, and assign pluginApi object to iframe window</li><li>plugins will obtain pluginApi simply via "api" object that has been assigned to iframe window by WebAdmin (no more parent.pluginApi)<br></li><li>this inversion of control allows more simple and secure way for plugins to interact with plugin API</li></ul></ul><ul><li>provide sandbox for plugin code running within an iframe</li><ul><li>use HTML5 iframe <span style="font-style: italic;">sandbox</span> attribute
[http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#attr-iframe-sandbox]</li><li>more specifically, disallow plugins to directly navigate to top-level document/window (e.g. parent)</li><li>reason: UI plugins are not meant to integrate with WebAdmin by directly manipulating top-level UI</li><li>instead, UI plugins are meant to integrate with WebAdmin via plugin API and events</li><li>if a plugin wants to extend UI, it should do it via plugin API and not by "hacking" top-level UI on its own<br></li></ul></ul><p></p><ul><li>remove <span style="font-style: italic;">resourcePath</span> from plugin descriptor, use <descriptorFileName>-files naming convention for static plugin resource directory</li></ul>Let me know what you think!<br><br>Vojtech<br><br><br></div></body></html>