Skip to main content

Trusted Advisor


Don’t abuse scope information

All the local variables of a screen and the results of queries or actions from the preparation are kept in the scope of the entire screen; this means they can be referenced in the preparation, the screen itself and the Screen Actions.

Impact - Think Viewstate

The screen scope is practical, but it should be used carefully in Screen Actions.

Keep in mind that a Screen Action execution is the result of a request to the Web Server, different from the initial request to the screen that generated the local variables and preparation data.

Any information scope required in all Screen Actions will be placed in the Viewstate that is sent back and forth between requests. Even if some data is required by only one of the Screen Actions, it will be passed to all the Screen Actions - because the viewstate is unique per screen. Sometimes information kept in the viewstate is not even used, simply because the Screen Action requiring that information is never hit.

In conclusion, the use of scope information in a Screen Action enlarges the viewstate, increasing the network traffic between the server and the browser. This is why Ajax can become slower and page load performance decrease.

Best practices

To limit the Viewstate growth, make sure you are not referencing large data from the scope in your Screen Actions. It is acceptable to reference local screen variables or the preparation result of a small type (e.g. an integer or an Id), but you should never reference any Structure, record list or large text.

Instead, do the following:

  • Reload queries and rerun actions - it is better to repeat the work at server side, than save these calls by reusing the result from the preparation at the cost of sending large information back and forth in the viewstate.
  • Pass information in Screen Action parameters - if certain information is used only by a screen action, passing it in a parameter instead of referencing the scope will guarantee that it will not be passed to other screen actions in the viewstate.

Parameters are also a clean way to pass the minimum context information to rerun queries or execute actions inside the Screen Action. For example, pass the TableRecord.List.Current.Customer.Id in a parameter instead of referencing it inside the Screen Action (which would make the entire TableRecord.List to be placed in the Viewstate).

  • Was this article helpful?