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 and the vSphere Web 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 /vsphere-client root path to the URLs.

■

Use the <plugin_namespace>.webContextPath variable defined in the web-platform.js JavaScript API to specify the Web context path for the Virgo server requests.

■

Use the vsphere-client 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.

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 ChassisA sample is defined in the manifest file as follows: 

Web-ContextPath: vsphere-client/chassisa

The root path for resources and data requests for the vSphere Client starts with ui while for the vSphere Web Client, the root path starts with vsphere-client/. If you leave the vsphere-client/ root path in the MANIFEST.MF and the URLs declared in the plugin.xml files of an HTML plug-in, you can still deploy the plug-in on both Web browser-based applications. The root path URL is transformed at runtime.

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 or the wizard provided with the vSphere Web Client Tools Eclipse plug-in 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>