Re: [Engine-devel] oVirt UI Plugins Presentation: PDF slides

Thanks Itamar! Please find my comments inline: You are right, "VDS" (org.ovirt.engine.core.common.businessentities.VDS) is indeed internal business entity, currently shared between backend and frontend. However, in slide "new application event, part 3", information about currently selected hosts (list of VDS) is not passed to plugins whatsoever - the slide only mentions that the contextObject passed to plugins "could carry data about hosts that were activated" (i.e. hosts currently selected after performing activate command). As you suggested, the contextObject is intended to carry Engine REST API-like representations of business entities, preferably using JSON notation for seamless integration with plugin (JavaScript) code. We'll most likely start with simple entity representations that only contain entity ID, and extend them later on (as you suggested). In fact, this is what I'm working on right now, as part of "custom context-sensitive button / menu item" plugin API feature :) That's correct, these slides were meant as the final part of the presentation ("Tips for implementing new plugin features"), they are not related to the previous ("Tutorial on writing simple plugin") part. The goal of these slides is to give community deeper insight on how to leverage existing plugin infrastructure to implement new features on top of it (new API function, new event to be consumed by plugins). Sample plugin git repo - sounds great! We could have one sample plugin per feature of plugin infrastructure, e.g. sample plugin that shows how to add main tab, etc. Very good idea! Could this be part of oVirt git repo (git://gerrit.ovirt.org/ovirt-engine) or should we use some other repo? "HostActivated" is just an example of how plugin callback (event handler) function can be called, in the situation when user clicks "Activate Host(s)" and plugins want to hook to this "event". The code presented on slides first invokes default (activate host) behavior [without asking plugins], and then gives all plugins the chance to do something in addition to that (through "HostActivated" event handler function). "HostActivateRequest" - could be implemented as well, IIUC - plugins would be asked if it's OK to proceed with host activation. This would be a separate plugin callback (event handler) function. Please correct me if I didn't understand your point correctly. Regards, Vojtech ----- Original Message ----- From: "Itamar Heim" <iheim(a)redhat.com&gt; To: "Vojtech Szocs" <vszocs(a)redhat.com&gt; Cc: "engine-devel" <engine-devel(a)ovirt.org&gt; Sent: Wednesday, October 10, 2012 9:35:36 AM Subject: Re: [Engine-devel] oVirt UI Plugins Presentation: PDF slides On 10/09/2012 12:39 PM, Vojtech Szocs wrote: great deck! few comments/questions: 1. you are using internal entities ("VDS") - the ui API must only use entities and actions which match the REST API entities/actions. or to begin with, make all these entities share IEntity, and just pass the IEntity.EntityId property for them to the plugin). 2. slides 21-25 iiuc, these are part of the plugin api infrastrcture, not of a sample plugin. i think a sample, simple, javascript plugin git repo would be great (like we have sample hooks for vdsm). 3. nit(?): the event you fire in the sample is not HostActivated, rather HostActivateRequest? i.e., need to distinguish between a request for an action, to a real status change of an object (which would be a change for a host entity in the grid from one status to a another status)?