User interface performance best practices

The ways in which you configure the user interface of your PolicyCenter instance affects its performance. As performance best practices for user interface configuration, Guidewire recommends that you always do the following:

Avoid repeated calculations of expensive widget values

As a performance best practice, Guidewire recommends that you avoid repeated evaluation of performance intensive expressions for widget values. Depending on the needs of your application, performance intensive expressions may be unavoidable. However, you can improve overall performance of a page by choosing carefully where to specify the expression within the page configuration.

For example, the following value range expression has a performance problem. Evaluation of the expression requires two foreign key traversals and one array lookup. If the PolicyPeriod instance is not cached, PolicyCenter executes three relational database queries, which makes the evaluation even more expensive.

RangeInput
...
valueRange     |policyPeriod.Policy.Product.AllowedPolicyTerms

If a page with this range input widget has any postOnChange fields, PolicyCenter potentially evaluates the expression multiple times for each postOnChange edit that a user makes.

The following topics provide additional suggestions for handling expensive expressions:

Use page variables for expensive value expressions

Instead of specifying an expensive expression as the value for a widget, create a page variable and specify the expensive expression as the initial value. Then, specify the page variable as the value for the widget. Page variables are evaluated only during the construction of the page, not during the remaining lifetime of the page, regardless of postOnChange edits.

The following example suffers a performance problem, because it assigns an expensive expression to the value property of a widget.

Input: myInput
  ...
  value        |someExpensiveMethod()

The following modified sample code improves performance. It assigns a performance intensive expression to a page variable and assigns the variable to the widget value.

Variables
  ...
  initialValue  |someExpensiveMethod()
  name          |expensiveResult

 --------------------------------
Input: myInput
  ...
  value         |expensiveResult

Use recalculate on refresh with expensive page variables cautiously

PolicyCenter evaluates page variables only during the construction of the page, but sometimes you want PolicyCenter to evaluate a page variable in response to postOnChange edits. If so, you set the recalculateOnRefresh property of the page variable to true. If a page variable specifies an expensive expression for its initialValue, carefully consider whether your page really must recalculate the variable. If you set the recalculateOnRefresh property to true, PolicyCenter evaluates the expression at least once for every postOnChange edit to the page.

Although PolicyCenter evaluates page variable with recalculateOnRefresh set to true for each postOnChange edit, page variables can yield performance improvements compared to widget values. If several widgets use the same expression for their values, using a page variable reduces the number of evaluations by a factor equal to the number widgets that use it. For example, the valueRange of a range input used for drop-down lists in a list view column are evaluated at least once for each row.

Avoid expensive calculations of widget properties

Page configuration widget properties editable, visible, available, and required, may need to be evaluated in multiple contexts. If you have a complex or expensive expression in one of these properties, move the expression to a page variable. Otherwise, the expression is evaluated several times before PolicyCenter displays the page.

The following example suffers a performance problem. It assigns a performance intensive expression to the visible property of a widget.

Input: myInput
  ...
  id             |myInput
  ...
  visible        |activity.someExpensiveMethod()

The following modified sample code improves performance. It assigns a performance intensive expression to a page variable. PolicyCenter evaluates page variables only once before it displays a page, regardless how many contexts under which it evaluates widget properties on the page.

Variables
  ...
  initialValue  |activity.someExpensiveMethod()
  name          |expensiveResult

 --------------------------------
Input: myInput
  ...
  id            |myInput
  ...
  visible       |expensiveResult

Use application permission keys for visibility and editability

The visible and editable properties are evaluated many times during the lifetimes of locations and widgets. As a performance best practice, Guidewire recommends that you structure the page configuration of your user interface so application permission keys determine visibility and editability. This is the most common pattern for user access in business applications.

For example, use the following Gosu expression in the visible property of a Renew button on a panel that displays information about a policy period:

perm.PolicyPeriod.renew(aPolicy)

Application permission keys evaluate the current user against general system permissions and the access control lists of specific entity instances.