1.16 Generic Commands |
|
1.16 Generic Commands |
|
This document explains how to create generic commands in Viewpoint.
A generic command is a way to perform any administrator-configured action on the Web server. Administrators set up generic commands to perform functions that are not part of Viewpoint's built-in commands. For example, cancelling a job is one of Viewpoint's built-in commands but editing a job's variable is not. To edit a variable on a job, an administrator can create a generic command that defines the action. Generic commands are represented as additional controls in the various management pages within Viewpoint. When a user clicks on a generic action, a popup window opens allowing the user to input values and submit the form.
All generic commands are configured in an XML configuration file. For generic commands dealing with jobs, the XML is added to the jobs.xml file. Generic commands dealing with VPCs are configured in vpcs.xml, etc.
Generic commands are configured in the same sections where other commands are configured. All configurable management pages allow for buttons at the top of a page to perform actions on a record without having to double-click on a record in the table. Also, most management pages allow for controls on the details section after double-clicking on a record.
In either of these locations, administrators can create any number of generic commands using <generic-command> elements. All <generic-command> elements should be a child of the <controls> parent.
A <generic-command> element has the following attributes:
id (Required) - This attribute is a unique id used to define the component. It will not be displayed to the user.label (Required) - This is the text that users will see for the generic action performed.tooltip (Optional) - This is the text that is displayed on the control when the mouse hovers over it.image-url (Optional) - This is the path to the icon that will be used to display the control.The following elements are children of the <generic-command> element:
header> (Required) - This element describes the header of the dialog box that is created.requirement> (Optional) - This element is a boolean value decider that determines if a record is valid for the action.components> Required) - This element describes the components that will be placed on the dialog box.command> (Required) - This element describes the command that will run on the Web server.The <header> element describes the header of the dialog that is shown when the user clicks the button to perform the generic action. It accepts one optional attribute, image, whose value is the location of an image on the Web server. The text of this element will be interpolated as the header of the new dialog box. The header can contain field references (keywords) that will be replaced with the value of the field of the current object being viewed. Allowable fields are the same as the allowable fields for the table and details sections.
<header image="image.png">Edit variable of $id!</header>
In this example, the "$id" keyword will be replaced with the ID of the object being modified. If this was the job management configuration and the user selected "job.15", then clicked the button created for the generic action Modify, the header would be "Edit variable of job.15".
Not all actions are applicable for all records. For example, the administrator may wish to only allow a node with a certain feature to have the ability to change IP address. In order to disable the generic action for some records, and re-enable the action for others, administrators should use the <requirement> element. This accepts any boolean value decider, and accepts all keywords corresponding to the applicable fields for the record in question. For example, the value decider can use "account", "id", "memory", and link to job fields for generic commands dealing with job records.
After the user selects a record and clicks on a generic command, a popup window containing various components is displayed. The components that should be displayed, along with any component rules and validation, are defined using the <components> element. This element is similar to all other places in the XML where components may be created.
The only difference with this section and all other component sections is the ability to specify a component's source. This means that when the popup window opens, the components can be automatically populated with values from the selected record. For example, a window that allows a user to modify a job's memory can auto-populate the "memory" component with that job's amount of memory. This is done using the optional <source> element. The <source> element contains only the property attribute.
For example, this component will auto-populate the component "textbox1" with the selected node's operating system:
<component id="textbox1">
<description>
Textbox auto-populated with OS
</description>
<source property="os" />
<text-value />
</component>
The administrator should specify at least one <command> element but may specify many more. This defines the actual command that runs on the Web server when the user clicks OK on the dialog box. The syntax for the commands is identical to any other place in the XML where we allow administrators to specify their own commands for various actions.
There are various places in the XML that allow administrators to specify Moab commands. Typically, these commands are used to create or fire triggers when a VPC is modified. However, Viewpoint supports any Moab command. To specify a Moab command, administrators should use the <command> parent element. Each <command> element has two child elements:
value> This is the command that will run on the server. It can be any string value decider. For each command, there are certain keywords that can be used to get the values of the objects that are being changed. For more information, see the specific action you are modifying.rule> (Optional) This element is a rule that must be evaluated to <true> in order for the command to execute. If this element is not set, the command will always run when the specific action takes place. This value can be any boolean value decider. Similar to the <value> element, there are certain keywords for each action that can be used to get the values of the objects being changed. For more information, see the specific action you are modifying.
<generic-command id="mycoolNodecmd" tooltip="This will allow you to edit the location of the reservation" label="Edit Location">
<header image="editLocation.png">Edit location of $id!</header>
<requirement comparison="equals">
<first>
<component id="variable[vm_os]" />
</first>
<second>linux</second>
</requirement>
<components>
<component id="textbox1">
<description>What is the desired location</description>
<source property="variable[vm_os]" />
<text-value />
</component>
<component id="textbox2">
<description>Textbox autopopulated with ip addr</description>
<source property="variable[ip-address]" />
<text-value />
</component>
</components>
<command><value>/home/user/tools/change_location $id</value></command>
</generic-command>