In the plugin.xml manifest file, each extension is defined in its own
<extension> element. The principal characteristics of the extension are described in their own elements, the
<extendedPoint> element for the extension point, the
<object> element for the extension object, and the
<metadata> element for filtering metadata.
The following example shows an example extension definition, starting with the <extension> element. The extension that the XML definition describes adds a data view to the object workspace for a Virtual Machine object. In the example, the data view is a section view for the
Summary tab in the object workspace for Virtual Machine objects. This example definition would appear in a plug-in module
plugin.xml manifest file where extensions are defined.
In the example, the <extension> element contains an
id attribute, which is a unique identifier that you create. Other extensions, such as extensions to the object navigator, can reference this extension using the
id attribute.
The <extendedPoint> XML element contains the name of the extension point. The vSphere Web Client renders the extension at the extension point when the new plug-in module is loaded. In
Example: Example Extension Definition in plugin.xml Manifest File, the extension point is
vsphere.core.vm.summarySectionViews.
The <object> element describes the required extension data object for the target extension point. The
<object> element uses standard XML syntax to describe a data object of the ActionScript class type that the extension point requires and sets values for the properties in that object. Each type of extension requires a specific extension data object. See
List of Extension Points.
Note In general, you do not explicitly specify the extension data object type. The <object> element is assumed to be an object of the type that the extension point requires. The
<object> element has an optional
type attribute that you can use to explicitly specify a type. You only need to explicitly specify a type if your extension definition provides a subclass of the extension point’s required class, or if the extension point requires an interface rather than a class.
In Example: Example Extension Definition in plugin.xml Manifest File, the extension point
vsphere.core.vm.summarySectionViews requires a class of type
com.vmware.ui.views.ViewSpec. The
<object> element describes how the
ViewSpec data object looks.
Objects of type com.vmware.ui.views.ViewSpec have a
<name> property and a
<componentClass> property. The
<name> property contains the name that the vSphere Web Client displays for the new data view extension. In
Example: Example Extension Definition in plugin.xml Manifest File, this name is “Sample Monitor View Title.” You can also specify a dynamic resource string for any
<name> property.
The <componentClass> property specifies the Flex class that implements the new data view. If you are implementing an HTML component, you specify one of the
htmlbridge Flex classes supplied by the SDK. Otherwise, you must create the Flex component. In
Example: Example Extension Definition in plugin.xml Manifest File, this class is
com.vmware.samples.viewpropertiesui.views.VmSampleSummarySectionView, which appears under the
Summary tab for virtual machine objects.
The <metadata> element contains filtering data that determines when the extension is available to the user. See
Filtering Extensions.
Example: Extension Filtered by Entity Type shows an example extension definition with filtering based on the selected object type. In the example, the extension actions appear only when the user has selected a Virtual Machine object.
You can use any vSphere or custom object type name as the value for the <objectType> element. To specify multiple object types, include two or more object type names in the
<objectType> element, separated by commas. You can also use the
* symbol to specify all object types. See
Naming Convention for vSphere Objects in the vSphere Web Client SDK.
You create the property value filter by describing one or more property value comparisons to be made on the selected object by using the <propertyConditions> element. You include the
<propertyConditions> element in the
<metadata> element in the extension definition. You can define a single comparison, or define multiple comparisons and conjoin those comparisons together.
In the <propertyConditions> element, you must describe a data object of type
com.vmware.data.query.CompositeConstraint using MXML syntax. Using the
CompositeConstraint data object, you specify the names of the object properties used in the filter, the desired value for each object property, and the comparison operator. You can also specify a conjoiner if your
CompositeConstraint data object has multiple comparisons.
In CompositeConstraint data object, you describe each property value comparison using the
<nestedConstraints> element. The
<nestedConstraints> element contains an array of data objects of type
com.vmware.data.query.PropertyConstraint. Each
PropertyConstraint data object represents one comparison between a given object property and a value you specify.
When you create a PropertyConstraint data object, you specify the object property to compare by using the
<propertyName> element, the value to compare against using the
<comparableValue> element, and the comparison operator using the
<comparator> element.
The value of the <propertyName> element must match the name of the object property to compare. You can set the value of the
<comparableValue> element depending on the type of property you are comparing, but the value must be a primitive type. You can use a string value, an integer value, or a Boolean value of
true or
false in the
<comparableValue> element.
You use the <comparator> element to choose how the property is compared against the value you specify in the filter. You can use values of
EQUALS,
NOT_EQUALS,
GREATER,
SMALLER,
CONTAINS,
EQUALS_ANY_OF or
CONTAINS_ANY_OF. If you use the
CONTAINS operator, you must provide an array of values. If you use the operators
EQUALS_ANY_OF or
CONTAINS_ANY_OF, you must provide a string containing multiple values in the
<comparableValue> element, each separated by a comma.
If your CompositeConstraint data object defines multiple comparisons, you can choose how those comparisons are conjoined by using the
<conjoiner> element. You can use a value of
AND or
OR in the
<conjoiner> element.
Example 2-3, on page 31, shows an example extension definition for an action extension. The extension is filtered based on the value of the property
isRootFolder, and whether the selected object has child objects of a particular type. In the example, the extension appears only when the value of the
isRootFolder property is
true, and the selected object contains child objects that are Virtual Machines.
You specify the privilege for which the object is valid by creating a <privilege> element inside the
<metadata> element in the extension definition. The extension appears only for users whose privileges include the value specified by the
<privilege> element. You can specify multiple privilege values in the
<privilege> element, separated by commas. If you specify multiple privileges, the user must have all of the specified privilege values for the extension to appear.
Example 2-4, on page 32, shows an example extension definition with filtering based on the user’s privileges. In the example, the extension appears only when the user’s privileges include
Global.Licenses.