Screen Phases

There are four phases you need to know about within the context of FNZ Studio Screens:

Update — During the Update phase, FNZ Studio persists any data the user has entered into the screen. This is when converters are evaluated; you can learn more about converters here.
Validate — During the Validate phase, FNZ Studio validates all of the data. FNZ Studio then generates validation errors if any of the data violates any validation defined. Validators are described here.
Process — If no validation errors are found, server-side Actions are executed during the Process phase.
Render — This is the phase when the HTML code for the corresponding screen is generated, and sent to the browser.

The phases are split into two separate groups: Three of the phases (Update, Validate, Process) are only executed when a screen is submitted to the server (e.g. when the user clicks on a button with a server-side action). One phase (Render) is only executed when FNZ Studio renders a screen. Note that if an action closes the screen instead of rendering another screen, the Render phase is not executed.

Let's take the screen rendering cycle as an example:

The user sees an FNZ Studio screen, and triggers a Server Action (e.g. clicks on the "Next" button)
The screen is submitted to the server (Phases: Update, Validate, Process)
FNZ Studio figures out which screen to render next (e.g. moves the token in a Process if no validation errors exist, or stays on the same screen if there are validation errors)
FNZ Studio draws a new screen (Phase: Render)

Depending on how you look at it, the whole cycle either starts either with the "Render" phase (if you just open FNZ Studio Runtime, you haven't yet submitted any data ) or with the "Update" phase: If you click a button with a server-side Action in an FNZ Studio screen, that's the first phase FNZ Studio executes.

Note: In this recipe I'm going to take the "Update" phase as the first phase in the cycle.

When the user clicks on a button with a server-side Action (or triggers a server-side Action in some other way), FNZ Studio submits the data the user has entered on the screen to the server, and goes through the first three phases: Update, Validate, and Process.

Once this is done — and if the user is in a process — FNZ Studio triggers the process engine, and moves the process token accordingly:

If there are validation errors, the process token remains on the same screen task, and the previous screen is rendered again.
If there are no validation errors, FNZ Studio typically finds the next screen task, and renders the corresponding screen.

The Render phase is then triggered; the HTML code for the corresponding screen is generated and sent to the browser. Finally, the browser renders the screen, and the user can click on another button, repeating the cycle.

Most of the time you can just ignore how these phases work. Phases become relevant, however, in certain specific situations:

If your screen is slow, it might be possible to skip some phases to increase speed
If you need to control the order in which scripts or Actions are executed, you can use phases to achieve this

Let's look at these two situations in turn.

Skipping Phases for Speed

Not all phases need to be executed in all situations. It is sometimes okay to skip some of the phases. If these phases take a long time to execute, skipping them can help improve screen performance.

So when can you skip phases?

You can skip the Update phase if the screen (or part of a screen) doesn't contain any bindings.
You can skip the Validate phase if the screen (or part of the screen) doesn't need to be validated (e.g. if the screen is redrawn due to an Ajax Update Action, and you don't want validation errors to pop up).
You can skip the Process phase if the screen (or part of the screen) doesn't have any Scripts or Actions that execute during the Process phase.
You can skip the Render phase if the screen (or part of the screen) doesn't change, and is cached (using the Screen Cache component).
You can skip the Render phase if the screen (or part of the screen) isn't shown to the user (e.g. if the screen is being redrawn due to an Ajax Update Action, you don't need to render parts of the screen that aren't in an Ajax Update Area that is being redrawn).

So how do you skip a phase? There are multiple ways to do this:

Screen Cache component You can use a Screen Cache component to skip the Rendering phase, and, optionally, the three other phases, for part of a screen.
Phase Control component You can use the Phase Control component to skip any of the Update, Validate, and Process phases, for part of a screen.
If component You can use the If component together with a call to the SCREENCONTEXT().inXXXPhase() (where XXX is the phase in question) to skip all phases, or specific phases.

You can even check if the request is an Ajax Update request using the IsAjaxUpdateRequest() function, in order to only skip phases when parts of a Screen are not updated in the browser, and therefore don't need to be redrawn.
Skip Phase Action You can use the Skip Phase Action to skip any of the Update, Validate, or Process phases for the whole screen.

Influencing the Phases

In certain circumstances, you may want to influence the phase in which something is executed in order to change the order in which Actions are executed:

Using the Phase property on Actions, you can specify in which phase (Update, Validate, or Process) the action is executed.
In the Phase property on the Script component, you can pick any of the four phases.
In the Ajax Update Area, you can change the Validation Scope: You can decide to either validate the whole Screen, just the content of the Ajax Update Area, or nothing at all.
An Action is not usually executed if the Screen has Validation errors (e.g. its Process phase will be skipped). You can override this behavior by checking the Action's Ignore Errors property.

We've created a printable poster (PDF) summarizing all of this information: Screen Phases poster