The metadata extension definition for a user interface extension specifies where the extension appears in the vSphere Web Client GUI, and provides information about how the extension’s appearance, including which Flex classes contain the actual GUI code.
The extension point represents the specific location in the vSphere Web Client user interface where the extension appears. The vSphere Web Client SDK publishes a set of extension points that correspond to specific locations in the user interface. See
List of Extension Points.
Each extension definition must specify one of the provided extension points. The vSphere Web Client SDK provides several extension points for adding new data view extensions to the Virtual Infrastructure object workspaces. Each of these points corresponds to an existing tab or sub-tab screen for a specific type of vSphere object. The SDK also provides extension points for other extensible GUI features, including the Object Navigator, Actions Framework, Related Objects specifications, and Home Screen shortcuts.
You can nest extensions. An extension can define its own extension points, creating a multilevel structure of extensions. The Virtual Infrastructure object workspaces use a nested structure of extensions. For example, tab screen extensions in an object workspace define extension points for sub-tab extensions, and subtab extensions define extension points for subtab views or portlets.
The extension object is a data object that describes the properties of the extension. You must provide a specific type of extension object for each extension point. Rather than instantiating the actual extension object, your extension definition must use MXML to provide a description of the required object.
The extension objects associated with each extension point correspond to specific ActionScript classes in the vSphere Web Client SDK. The properties of the ActionScript class are used in the data object to specify things like labels and icons for the extension. In the cases of data views, actions, and certain extensions to the Object Navigator, you also use the extension object properties to specify the Flex classes that you have created for those extensions.
You can include filtering metadata in your extension definition. You can use filtering metadata to control when the user has access to a given extension. For example, you can filter an extension to appear only for certain types of objects, or when an object’s property has a specific value. Filtering metadata is optional and not required for every extension definition.
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.
Example: Example Extension Definition in plugin.xml Manifest File shows an example extension definition, starting with the
<extension> element. The extension described by the XML definition 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 extension definition would appear in the 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 of your choice. 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 MXML 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 need only 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. You must create this Flex component, which appears as a subtab screen in the
Monitor tab for Host objects. In
Example: Example Extension Definition in plugin.xml Manifest File, this class is
com.vmware.vsphere.client.sampleplugin.SampleObjectView.
The <metadata> element contains filtering data that determines when the extension is available to the user. See
Filtering Extensions.
In your extension definition, you can use filtering metadata to control when the extension appears in the vSphere Web Client GUI. You can filter extensions based on the selected object type, on the value of any property associated with the selected object, or on the user’s privilege level. You set the filter type and the specific filter values by using the appropriate XML elements inside your extension definition’s
<metadata> element.
You can filter your extension to only appear when the user has selected one or more specific types of vSphere objects. You specify the types of objects for which the extension is valid by creating an
<objectType> element inside the
<metadata> element in the extension definition. The extension appears only when the user has selected an object whose type matches the value of the
<objectType> element.
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
* operator 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 inside the
<metadata> element inside 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 you want 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 you want 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 CompositeConstrant 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: Extension Filtered by Entity Property Value 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 can filter your extension to only appear for users that have a specific privileges. You can base your filter on global privilege settings in the vSphere Web Client, such as settings or licenses. For example, you can use a filter to make your extension available only to users that have global privileges to change settings.
You can also filter your extension based on privileges related to specific types of vSphere objects. For example, you can use a filter to make your extension available only to users who have privileges to create or delete
Datastore objects.
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: Extension Filtered by User Privileges shows an example extension definition with filtering based on the user’s privileges. In the example, the extension appears only when the user’s privilege include
Global.Licenses.