A user interface plug-in module is a Web Application Archive (WAR) bundle. The WAR bundle contains all of the resources and Flex classes required for each GUI element the module adds to the vSphere Web Client interface. In a user interface plug-in module, the GUI elements you add to the interface are called extensions.
In the root folder of the WAR bundle, you must create a manifest file called plugin.xml. The
plugin.xml manifest file uses metadata to define the plug-in module’s extensions and resources.
The plug-in module manifest file, plugin.xml, is a metadata file that the vSphere Web Client container application uses to integrate the extensions in the plug-in module with the rest of the interface. The
plugin.xml file fulfills the following functions.
The metadata in the manifest file follows a specific XML schema. The major XML elements of a user interface plug-in module manifest include the
<plugin> element, the
<resources> element, and one or more
<extension> elements. The vSphere Web Client SDK contains several examples of user interface plug-in modules with complete
plugin.xml manifest files.
The <plugin> element is the root element of any plug-in module manifest file. All other elements are contained within the
<plugin> element. The attributes of the
<plugin> element contain information about the entire plug-in module.
|
■
|
id. The unique identifier that you choose for the plug-in module.
|
|
■
|
moduleUri. A Uniform Resource Identifier (URI) for the SWF file in the plug-in module. The SWF file contains the Flex or ActionScript classes used by the extensions in the plug-in module. The URI should be specified relative to the root directory of the plug-in module WAR bundle.
|
|
■
|
securityPolicyUri. A URI for a standard cross-domain security policy file. This optional element is used when the plug-in module is hosted remotely (and the domain of the plug-in module URL is different from the domain vSphere Web Client application server). For more information on specifying a cross-domain security policy file, go to http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html.
|
|
■
|
defaultBundle. The name of the default resource bundle for the plug-in module. The bundle name must be unique to your plug-in module to avoid name clashing issues with other plug-in modules. Resources, such as localization data and icons, can be dynamically loaded at runtime. See Specifying Dynamic Resources.
|
The following XML fragment shows how the <plugin> element might appear in the plug-in module manifest file.
The <resources> element is used to specify the location of the plug-in module’s runtime resources, such as localization data. In general, resources are bundled in separate SWF files from the SWF file that contains the plug-in module Flex classes.
The vSphere Web Client supports the same set of locales as vCenter server. The default locale is the locale set the by the user’s web browser. If the user’s web browser is not set to a locale that the vSphere Web Client supports, the vSphere Web Client will default to the English (United States) locale.
It is a best practice to set the locale attribute in the
<resource> element to the value
{locale}, rather than hard-coding a specific locale, in your plugin.xml manifest. Using the
{locale} value instructs the vSphere Web Client to use the locale specified by the user’s Web browser at runtime.
For the vSphere Web Client to properly import the resource locale at runtime, resource bundles for all supported locales must be included in the plug-in module. Currently supported locales include English (United States) (en_US), French (fr_FR), German (de_DE), Japanese (ja_JP), Korean (ko_KR), and Mandarin Chinese (zh_CN) locales. For testing purposes, you can make simple copies of the default locale for any languages for which you do not have resources available. The sample plug-in modules included with the vSphere Web Client SDK demonstrate this method.
The following XML fragment shows how the <resources> element might appear in the plug-in module manifest file.
In the preceding example, the {locale} placeholder corresponds to a particular locale, such as
en_US for English. Your plug-in module must contain a separate .SWF resource bundle for each of the supported locales, using the relative path in the preceding example.
Your extension definitions can use the dynamic resource loader to load resources or localization data at runtime. When you have specified a
<resources> bundle in the manifest file, the
<extension> elements in the manifest file can specify that bundle by reference. Resource specifications in the
<extension> elements should use the expression
#{bundle:key} when specifying resources, where
bundle indicates the name of the resource bundle, and
key indicates the resource to use.
For example, within an <extension> element in the
plugin.xml file, you can specify an icon resource to be loaded dynamically at runtime by using following the expression.
Specifying a dynamic resources allows you to avoid using a static value for the icon resource. The bundle name must specify a resource bundle that you have made available in the
<resources> element of
plugin.xml.
You can also omit the bundle name from a resource expression:
The plug-in module manifest file must define each individual extension that the plug-in module adds to the vSphere Web Client. Each extension is defined using the
<extension> element. The
<extension> element contains information about each feature, and its exact composition varies depending on the kind of user interface element your plug-in module is adding. See
Defining Extensions.
You can use the <precedingExtension> element to specify the order in which the vSphere Web Client renders the extensions in your plug-in module.
Within each <extension> element, you can specify a
<precedingExtension> element that contains the ID of another extension that is to be rendered before the current extension. Setting the value of
<precedingExtension> to NULL will cause that extension to be rendered first.
If no <precedingExtension> value is specified, the extensions are rendered in the order they appear in the
plugin.xml module manifest file. If multiple extensions specify the same value for
<precedingExtension>, they will be rendered after that specified extension in the order in which they appear in the manifest.
The following XML fragment shows how the <precedingExtension> element might appear in the extension definitions in the plug-in module manifest file.
The <precedingExtension> elements in the example ensures that the
PerformanceView extension is rendered first, followed by the
UtilityView extension.