Guidelines for Creating Plug-Ins Compatible with the vSphere Client

You can use the plug-in generation scripts provided with the vSphere Client SDK to create a plug-in that is compatible with both Web browser-based applications.

To develop an HTML plug-in, you must first create a plug-in project that has the required by the plug-in resources and directory structure. Use one of the generation scripts that are available in the tools\Plugin generation scripts folder under html-client-sdk.

After you create the HTML plug-in project, follow these guidelines to ensure that your plug-in is compatible with the vSphere Client:

Use relative URLs to set the location to the resources inside your plug-in inside your HTML and JavaScript code. For example, you must avoid adding the /ui root path to the URLs.
Use the ui root path only inside the MANIFEST.MF and plugin.xml files.
Add Cascading Style Sheets (CSS) classes to the plugin-icons.css file for the icons that are displayed outside the views, such as Home screen shortcut icons, menu icons, and vSphere objects list icons. See Handling Icons Outside the HTML Views.
When you add an extension to an existing object menu or a custom object menu, you must define a custom menu extension referencing the vsphere.core.menus.solutionMenus extension point in addition to the actions referencing the vise.actions.sets extension point. See Defining Menus and Sub-Menus.

Note: For the vSphere 8.0 release, local plug-ins must be upgraded as follows:

Local plug-ins must be FIPS-compliant. See https://developer.vmware.com/docs/13385/preparing-local-plug-ins-for-fips-compliance
Local plug-ins must bundle third-party libraries and installthem in a separate directory. See https://vdc-download.vmware.com/vmwb-repository/dcr-public/77dd6491-bb96-47f3-8c2e-a5a4655f078b/b916bc3c-0168-4487-a9e5-c89b50373c18/Local-Plugins-Library-Isolation.pdf

Using the Web Context Path in HTML Plug-Ins

Each HTML plug-in is a separate Web application that has a specific context path defined in the MANIFEST.MF file of the WAR bundle. The context path of your application specifies where the Web content is hosted and which requests must be handled by your application. For example, the Web context path for the HTML sample plug-in is defined in the manifest file as follows:

Web-ContextPath: ui/html-sample

The root path for resources and data requests for the vSphere Client starts with ui.

Handling Icons Outside the HTML Views

External icons are the icons displayed outside the HTML views and handled directly by the vSphere Client. Examples of such icons are the Home view shortcut icons, menu icons, and the vSphere object list icons. If you use the generation scripts to generate your HTML plug-in, the plugin-icons.css CSS file is added to the plug-in project. The example CSS file contains the definitions of two external icons.

To declare that your plug-in depends on external icons, in the plugin.xml manifest file add the <dependency> element inside the <dependencies> element. The following attributes of the <dependency> element contain information about the external icons:

type - The resource type such as css.
uri - The URI of the CSS file that contains the external icon declarations.

Following is an example of dependency declaration in the plugin.xml file:

   <dependencies>
      <!-- Allow HTML Client to display icons in menus, shortcuts, lists -->
      <dependency type="css" uri="myplugin/assets/css/plugin-icons.css" />
   </dependencies>

Defining Menus and Sub-Menus

When you add a custom vSphere object menu or extend an existing object menu, you must define each individual action and add a custom solution menu under the existing menu which might include sub-menus and separators. Use the vise.actions.sets extension point to define each action, and the vsphere.core.menus.solutionMenus extension point to add the custom solution menu.

The following example demonstrates how you can define custom actions for VirtualMachine objects and then add custom solution menus under the existing VirtualMachine menu.

   <extension id="com.vmware.samples.vspherewssdk.vmActionSet">
      <extendedPoint>vise.actions.sets</extendedPoint>
      <object>
         <actions>
            <com.vmware.actionsfw.ActionSpec>
               <!-- UI action: show dialog -->
               <uid>com.vmware.samples.vspherewssdk.myVmAction1</uid>
               <label>#{action1.label}</label>
               <delegate>
<className>com.vmware.vsphere.client.htmlbridge.HtmlActionDelegate</className>
                  <object><root>
                     <!-- execute the action on client-side (html view in a modal dialog) -->
                     <actionUrl>/vsphere-client/vspherewssdk/resources/vm-action-dialog.html</actionUrl>
                     <dialogTitle>#{action1.label}</dialogTitle>
                     <dialogSize>500,250</dialogSize>
                  </root></object>
               </delegate>
            </com.vmware.actionsfw.ActionSpec>
      </object>
      <metadata>
         <!-- Filter this extension only for VirtualMachine objects -->
         <objectType>VirtualMachine</objectType>
      </metadata>
   </extension>
            ...

   <extension id="com.vmware.samples.vspherewssdk.vmMenu">
      <extendedPoint>vsphere.core.menus.solutionMenus</extendedPoint>
      <object>
         <!-- <label> is required here because it is an extension to an existing menu -->
         <label>#{solution.label}</label>
         <children>
            <Array>
               <com.vmware.actionsfw.ActionMenuItemSpec>
                  <!-- UI action example -->
                  <type>action</type>
                  <uid>com.vmware.samples.vspherewssdk.myVmAction1</uid>
               </com.vmware.actionsfw.ActionMenuItemSpec>

            ...
       </object>
       <metadata>
         <!-- Filter creates this extension only for VirtualMachine objects -->
         <objectType>VirtualMachine</objectType>
       </metadata>
   </extension>