vSphere hybrid plugin collisions

[jvitorino]

Hi,

We have developed a hybrid (flex/html) plugin that has been working for use for some time when we deploy the plugin in vSphere Web Client (6.0 and 6.5) as well as the vSphere Client (6.5).  As we continue to migrate our functionality from Flex to HTML, we have some HTML dialogs that haven't quite reached parity with our Flex dialog and therefore would like to continue to use the Flex dialog for the Flex Web Client and start to use the HTML dialog in the HTML client. 

Looking at the documentation, it seems like some of the views may support an "html" suffix (<namespace>.summarySectionViews.html) which I assume means that it will only be displayed in the HTML client.

We are wondering if there is a way to control whether or not other UI elements are displayed in the Flex Web Client vs. the HTML Client?  Our current issue is with a global action for a custom object.  Is there any metadata condition to have actions only display in HTML?  We are defining an ActionSpec to open the Flex dialog and we've added a new ActionSpec for the HTML dialog however we're seeing collisions and/or duplicate actions rendered.

I'm sure that we'll be running into other collisions and may soon need to produce two different plugins, however we are hoping to get a little more mileage out of the single plugin approach.

Thank you,

Jesse

[laurentsd · Accepted solution]

hi Jesse,

The SDK 6.5's .pdf document "Getting Started with HTML  Client SDK" describes the overall strategy for hybrid plugins.

If you have 2 menu actions, one opening a Flex dialog and the other one opening the HTML version, it would be tricky to control which one to show. So my first question is why can't you use the HTML dialog in all cases since it is supported by the HTML bridge?

Controlling the visibility of an action extension can be achieved with a property condition in the <metadata> section, like it is for any extension.  The tricky part is that you will need to implement a property provider that knows whether the user is logged in with the HTML client or the Flex client.  I don't have any answer to that at the moment.

[jvitorino]

Thank you for the quick response.  Our HTML dialogs haven't reached feature parity quite yet and therefore we were hoping to use the full-featured Flex dialog where we can (Flex Web Client) and the HTML dialog in the web client (fewer features is better than none 🙂 ).

We were thinking of the property provider approach as well and came to the same "catch" regarding the knowledge of which client the request came from.