Event processing with action sets
A user interface (UI) can include controls that allow users to perform certain actions before submitting a form to provide a more interactive user experience.
The event-action model
Actionable controls are based on an event-action model, which establishes a cause-and-effect relationship for a control such as a check box or a button. The event is a trigger caused by user activity, such as a button click or field entry. The action is a response by the application, such as creating a case or displaying information about a field to guide user input.
For example, an online retailer wants to allow customers to use the shipping address for an order as the billing address for payment. The form for entering the billing address provides users with a check box. When the user selects the check box, the application copies the shipping address information to the billing address fields and disables any editing of the billing address fields. When the user clears the check box, the application removes any entries in the billing address fields and allows the user to enter an address.
In the center of the following image, slide the vertical line to view how the display of the address form changes when the user clicks and clears the check box:
The following table lists examples of event-action pairs:
| Event | Action |
|---|---|
| Click a control such as a button, link, or icon | Open a new window |
| Double-click a row in the grid | Allow editing of the contents of the row |
| Press the Enter key on the keyboard | Display a menu |
| Select a value from a list of states or provinces | Update the list of office locations |
| Enter a value in the Quantity field | Verify that inventory is sufficient to fulfill the order |
Action sets
In a Pega Platform™ application, you use an action set to configure an actionable control. An action set consists of one or more events and one or more actions. Optionally, you can add conditions to each action so that the action occurs only when the conditions are met.
In the following image, click the + icons to explore how an action set can populate the billing address fields on a form when submitting an order to an online retailer:
Check your knowledge with the following interaction:
Action set optimization
When configuring an action set, consider how the user experience and data are affected by refresh actions and calls to the server. For example, the user flow is interrupted when the user has to wait for a screen to refresh or return to a previous screen manually.
Refresh a section when:
- Property values are updated on the server, and the UI needs to reflect the new values.
- An action that causes a change to more than one property that occurs only on the client, such as deleting a row, must be submitted.
- Parts of the UI require removal from the Document Object Model (DOM) because of other input.
Do not refresh a section when:
- You need to submit user input. Instead, use a post value action.
- You need to call a data transform or an activity after a user action.
- You need to recalculate visibility, enabled/disabled state, or read-only state. Select the Evaluate on client check box next to the expression field.
Use a Refresh When action whenever possible to declare dependencies. To maintain accurate data, use a Refresh When action for read-only references that need to remain synchronized with data on the server. For example, refresh a hotel details section that needs to be updated only when the hotel location changes.
When a Refresh When is not possible, use a Refresh Other Section action, which is a targeted refresh. For example, if you have editable references that are updated based on other input or based on untrackable inputs, such as button clicks, use the Refresh Other Section.
Consolidating actions in the action set
Each action in the action set generates at least one HTTP request to the server and runs in the sequential order of configuration. To optimize the actions and reduce the number of HTTP requests to the server, use the following best practices:
- If the pre-activity or pre-data transform runs in the same context as the section refresh, configure them in the refresh section action.
- Modify the content of your pre-activity if needed when running it in the context of the refresh section.
- Use wrapper activity or wrapper data transform to consolidate all the actions.
In the center of the following image, slide the vertical line to view how the actions in an action set can be consolidated into a wrapper activity:
Differentiating between post and refresh section actions
By default, a Refresh section action sends all the pending changes applied to a form back to the server. There is no need to use a Post value action before a refresh section action, such as a Refresh This Section action.
A Post value action will update the server and force all the Refresh When conditions to reevaluate. One Post value action can affect several sections using when conditions. Use one Post value action instead of using a Refresh section for each one of these sections. Using a Post value action to refresh all the sections also avoids hardcoding the section name in the action set when using a Refresh Other section.
For example, in a vehicle purchase application, a user enters their Customer ID to view additional accessories. When the Customer ID value changes, the conditions on two sections are evaluated against stored customer data, such as Elite membership status, active membership length, and total vehicle purchases. The Exclusive lifestyle accessories section refreshes only when a valid Customer ID is associated with a user who has purchased three or more vehicles. The Elite car accessories section refreshes only when a valid Customer ID belongs to a user who has been an active Elite member for more than 10 years.
In the center of the following image, slide the vertical line to compare the view displayed for an invalid user with the view displayed for an Elite member:
This Topic is available in the following Module:
Want to help us improve this content?