Html SDV V6.7U1 - local plugin - using the htmlClientSdk for actions instead of WEB_PLATFORM

[CathyBr]

Hi I'm workfing on removing the references of WEB_PLATFORM from our plugin, and have come across 2 dificulties.

1) We have some generic action templates which we use, and load our classes depending on the actionUID.

So when the action dialog is started, we use:

WEB_PLATFORM.getActionUid() .

So I wanted to change it to the htmlClientSdk api, but there is no method for getting the ActionUid - or am I missing something?

2) When an action is defined in the plugin.xml and is started, I want to use the htmlSdk within the dialog, but when I try to retrieve it:

     var htmlSdk = window.frameElement.htmlClientSdk;

it is undefined...

Is there an other way I can retrieve it?

thanks for the Info

Cathy

[Denis_Chorbadzh · Accepted solution]

Hi Cathy,

For the first question, there is no alternative for "getActionUid()" in the new JS APIs. The recommended approach is to have different controllers for different actions.

For the second question, this is the right way to get the new APIs - "window.frameElement.htmlClientSDK". Just make sure you are using the new classes:

<className>com.vmware.vsphere.client.HtmlPluginHeadlessAction</className> - for a headless action

<className>com.vmware.vsphere.client.HtmlPluginModalAction</className> - for an action which invokes a modal dialog

Please refer to the HTML Sample plugin where these are used.

Best Regards,

Denis

[CathyBr]

Hi Denis,

thanks very much for the info!

1)  Have different controllers fo different actions.

ok - this is possible  - but somewhat clumsy I think - We don't use angular, everything is done in htm5 + java script -so this means lots of extra files which are not needed - but that is ok.

2)  We still have to support FLEX - so at least at this time we are still using the htmlbridge - our action class is based on

com.vmware.vsphere.client.htmlbridge.HtmlActionDelegate -

As long was WEB_PLATFORM ist still working  we will use this, and when it is no longer available (7.0)  we'll change the plugin.xml definitions.   But then we will be forced not to support flex.

Our support usually works like this - we support the highest Update version of the last 2 Versions - so right now we have to support

vSphere V6.5 U2 - still has flex

vSphere V6.7 U2 (Many Customers still have U1).

thanks for your help!

Cathy

[_vladi_]

Hi Cathy,

My 2 cents:

1) I understand. Indeed we are moving into a more explicit model with the plugin owning its navigation (without breaking backward compatibility of existing plugins). This allows for more flexible development of future APIs without impact on the ecosystem. If samples and documentation are insufficient to consume this please do let us know to improve it.

2) Your compatibility setup sounds logical and it is great you look into moving to newer APIs. Just keep in mind the removal of vSphere Web Client (Flash) in a future release would not force you into migrating your plugin. What would happen is: Flash would disappear and your Bridge plugin will keep on working on the vSphere Client (HTML). Bridge plugins are deprecated but right now there are no plans / firm decision to stop supporting them at a particular release of the vSphere Client (HTML). This would depend on the adoption rate of the recommended APIs and Remote plugins.

Hence, partners can prioritize and decide how to proceed: keep the Bridge plugin for a while, migrate to a local plugin based on new JS APIs or go for a Remote plugin. Of course we recommend the latter 2 options given they provide better support for modals, refresh, dark theme, etc. Check the SDK home pages for hints about what any of these choices include.

Cheers,

Vladi