6.1 About Forms
Forms allow the user to request a resource, approve a resource request, and work on a task. They are available when the user chooses any of the actions in the category of the User Application’s tab. Forms are also available directly from a URL. For details on this technique, see Section 6.9, Providing Direct Access to a Form.
Figure 6-1 is an example of a resource request form. At the top of the form is a read-only area that displays the details of the request (or approval for approval forms). In the section at the bottom, the user provides input to the resource request (or approval) and takes some action on it.
Figure 6-1 Sample Form
You use the tab of the provisioning request definition editor to define the appearance and behavior of the section of the User Application’s requests and approvals forms.
About Request Forms
You can create one request form for a provisioning request definition. The request form is associated with the workflow’s Start Activity.
Figure 6-2 Sample Resource Request Form
About Approval Forms
You can define multiple approval forms for a provisioning request definition, but only one form per Approval Activity. You can specify the approval form to associate with an approval activity in the properties for the activity. You can create an approval form via the tab or from the approval activities property sheet.
Figure 6-3 Sample Resource Approval Form
6.1.1 About Form Control Data Binding
All of the fields you define for a form are automatically available for data binding in the Data Item Mapping property sheet. Two bindings, or mappings, are possible for each form field: a pre-activity mapping to initialize or pre-load a form field with data, and a post-activity mapping to move modified form data into the workflow document called flowdata. These data-item bindings and any script expressions they utilize execute on the application server as preparation of the form before it is sent to the client browser for display to the user. Common uses for pre-activity data-item mappings and their expressions that operate against the flow-data document are for moving previous approval data into the current approval or for setting default values for fields. For more information on data item mappings, see Section 7.2.2, Defining the Data Item Mappings.
Some form controls allow you to initialize their values from data sources other than workflow data. For example, some list controls allow you to specify the initial value as a property of the control. For more information about defining initial values, see Section 6.5, Form Control Reference.
6.1.2 About Forms and Events
Designer allows you to define action scripts that execute on the form control’s onLoad, onChange, or custom events. Each form control supports an Events property where you supply the script for the event. The scripts you define have an event-level scope and execute in the browser of the user’s client machine.
The Events property provides access to Designer’s Event Action Expression Builder, which allows you to create script expressions that refer to and modify form and data. Since form control event scripts execute in the client browser, they do not have access to the flow-data document. They do have access to directory abstraction layer queries.
Figure 6-4 Event Action Expression Builder
The Event Action Expression Builder also provides access to the Form Action methods (shown in the left column). This column provides access to the form action script API along with directory abstraction layer query objects. The form action script API is written in JavaScript* so that you can add conditions, loops, and user-defined functions. For more information about the Form Action API, see Section 10.3.1, Form Action Script Methods. To import or include a JavaScript library, you use the tab of the Form Controls area. For more information, see Section 6.3.4, Using the Scripts Tab.