Web Development
What the Web Development domain tests
This domain tests how you build screens and move data in Traditional Web and Reactive Web apps: screen lifecycle, data fetching, actions, validation, and session state.
Core rules
- Traditional Web renders on the server. The Preparation runs before the screen renders; screen actions handle postbacks; Ajax Refresh updates part of the page without a full reload.
- Reactive Web runs in the browser. Screens have OnInitialize, OnReady, OnRender, and OnDestroy. Use Data Actions to run aggregates or server logic; client actions cannot query the database directly.
- Variables have scope: input, local, output, session, client, and site properties. Use input parameters for screen contracts and local variables for UI state.
- Validation belongs close to the data. Built-in input validations catch format errors; server actions must still enforce business rules because client checks are bypassable.
- Use screen roles and action roles for authorization, not conditional visibility alone.
Worked example
A Reactive search screen has an input bound to SearchText and a list bound to a Data Action aggregate filtered by SearchText. On the search button click, a client action assigns the input to SearchText and calls the Data Action; the aggregate runs on the server and returns the rows. Reasoning: the client action cannot run the aggregate itself, and the Data Action is the supported server-side boundary. In Traditional Web, the same behavior would use a screen input parameter, a Preparation aggregate, and an Ajax Refresh on the list.
Traps
Calling aggregates from client actions, expecting a Preparation in Reactive Web, storing screen state in session variables, and skipping server-side validation because the UI already validates.