Appearance
Page Flow
Page Flow defines the browser-side behavior of an individual Page or Form in an ioLoop Project.
Use Page Flow to respond to user actions, update Page Elements, validate input, open Forms as modals, coordinate Widgets and Data Design, work with permitted Project data, and invoke Cloud Flow when trusted server-side processing is required.
The Page Editor defines the visual interface. Page Flow defines how that interface behaves and responds to events. Each Page or Form has its own Page Flow, allowing its behavior to be developed and maintained alongside its content.
Page Flow combines visual programming blocks with JavaScript code blocks. Common behavior can be assembled visually, while focused custom JavaScript can be used when the available blocks are not the clearest solution.
What You Can Build with Page Flow
Page Flow supports a wide range of interactive application behavior.
| Capability | Typical Use |
|---|---|
| Startup logic | Load initial data, read URL parameters, set default values, or prepare the Page when it opens. |
| Event handling | Respond to Buttons, menu interactions, input changes, Form events, and supported Widget actions. |
| Page content and styling | Read or update Page Elements, control visibility, change content, and apply supported presentation changes. |
| Forms | Open Forms as modals, pass edit data or shared context, and handle the outcome of a Form workflow. |
| Widgets | Refresh or coordinate Data Tables and other supported Widgets. |
| Data Design | Prepare data and render repeated visual content into a target area on the Page. |
| Project data | Read, create, update, or delete records through supported client-side operations, subject to Database access rules. |
| Cloud Flow | Call server-side web hooks and handle their returned results. |
| Custom JavaScript | Perform a focused calculation, transform data, or use supported browser-side ioLoop APIs. |
For example, a customer-management Page can use Page Flow to load records, open an Add Customer or Edit Customer Form, pass the appropriate context, and refresh a Data Table after a successful operation.
How Page Flow Works
Page Flow is assembled in a visual canvas using blocks from a toolbox. Blocks represent events, actions, values, conditions, data operations, and other programming constructs.
The basic workflow is:
- Open a Page or Form in the Page Editor.
- Choose Flow to open that item's Page Flow editor.
- Find the required blocks in the toolbox or its Search area.
- Connect blocks into the intended sequence and configure their inputs.
- Use Custom Code or Code Expression blocks for focused JavaScript when appropriate.
- Save the Page Flow to generate the JavaScript used by the Page runtime.
- Preview the Page or Form and test the complete interaction.
If a flow references Page Elements added or changed in the visual canvas, save the Page content before configuring those references so Page Flow can use the current saved structure.
Saving Page Flow retains its development changes; it does not, by itself, publish a new application version. Publish the Project separately when the tested changes are ready for users.
For canvas controls, toolbox navigation, block Help, clipboard operations, and saving behavior, see Editor Basics.
The Page Flow Execution Model
Page Flow runs in the user's browser. Its behavior commonly begins in one of two ways:
| Trigger | What Happens |
|---|---|
| Startup | Logic runs as the Page or Form opens to initialize its state or prepare initial content. |
| Event | Logic runs in response to a user action, Form lifecycle event, or supported Widget interaction. |
Some operations, such as Project data requests or Cloud Flow calls, complete asynchronously. When subsequent actions depend on the result, handle them through the appropriate success, failure, or completion path instead of assuming the result is available immediately.
For larger flows, use clearly named procedures and keep related logic organized. This helps separate initialization, user interactions, data loading, and result handling.
See Events and Startup for lifecycle and event-driven patterns.
Page Flow, Page Elements, Forms, and Widgets
Page Flow coordinates the interface that the Page Editor creates.
For example, an event registration application might use:
- A Page to display an event and its registration controls.
- A Button whose Page Flow opens a registration Form as a modal.
- Shared context to tell the new registration Form which event was selected.
- The Form to collect and validate attendee information.
- A permitted Database operation or Cloud Flow, as appropriate, to process the registration.
- The opening Page's Page Flow to update availability or show a confirmation after the operation succeeds.
The Page Flow that opens a modal and the Form's own Page Flow have different responsibilities. The opening Page coordinates the interaction and responds to the result. The Form handles its internal initialization, validation, and submission behavior.
Likewise, a Data Table Widget supplies a record-oriented interface, while Page Flow can coordinate its refreshes, custom actions, and related Form workflows. Data Design supplies a reusable item layout, while Page Flow can prepare data and coordinate rendering repeated instances into the Page.
For these patterns, see Forms and Widgets, Opening Forms as Modals, and Rendering Data Design.
Page Flow and Cloud Flow
Page Flow and Cloud Flow serve different execution environments and responsibilities.
| Need | Recommended Approach |
|---|---|
| Respond to a Button, update visible content, or open a modal | Page Flow |
| Validate input for immediate user feedback | Page Flow, with trusted validation where required |
| Read or update Project records permitted to the current user | Supported Page Flow data operations |
| Process a request using private credentials | Cloud Flow |
| Enforce protected authorization or important business rules | Trusted Backend capabilities, including Cloud Flow where appropriate |
| Call an external service requiring secrets | Cloud Flow or the appropriate trusted Integration workflow |
| Update the Page after server-side processing | Page Flow handles the result returned by Cloud Flow |
Page Flow can access Project data through supported client-side operations, subject to the configured Database permissions. It is not necessary to use Cloud Flow for every data read or update.
However, Page Flow is not a security boundary. Its code runs in the visitor's browser. Hiding a control, disabling an action, or validating a value only in Page Flow does not authorize or secure a protected operation. Enforce sensitive permissions and business rules through Database access controls and trusted Backend processing.
For details, see Data and Cloud Flow and Cloud Flow.
Visual Blocks and Custom Code
Visual blocks are the preferred way to express the overall Page Flow structure. They make the sequence of events and operations easier to inspect and maintain.
Page Flow also includes two JavaScript-oriented block types:
| Block | Purpose |
|---|---|
| Custom Code | Runs JavaScript statements for focused browser-side logic. |
| Code Expression | Produces a value from a single JavaScript expression for another block to use. |
Use custom code for specialized logic rather than moving an entire workflow into one large code block. Keep security-sensitive work outside browser-side JavaScript.
When Page Flow is saved, ioLoop validates enabled Custom Code and Code Expression blocks. Invalid JavaScript can prevent the save until the error is corrected.
See Custom Code for editing, expressions, and validation.
Testing and Publishing
Use Preview to test Page Flow against the current development version of the Project before publishing.
Test the complete user experience, including:
- Startup behavior and initial data loading.
- Buttons, navigation, and event handlers.
- Form opening, shared context, edit data, submission, close, and cancel behavior.
- Widget refreshes and Data Design rendering.
- Successful and failed Database or Cloud Flow operations.
- Loading, empty, and error states.
- Access-dependent behavior for the intended Project Users.
- Desktop, tablet, and mobile interactions where relevant.
If an operation fails, check that its blocks are enabled and correctly connected, its element or Project resource references are valid, its required data is available, and the current user has the appropriate permissions.
Preview may invoke real data operations or services, depending on the Project's configured environment. Test with the intended data and connections rather than assuming every Preview action is side-effect-free.
See Previewing and Troubleshooting for a more detailed testing and debugging checklist.
In This Section
| Guide | What You Will Learn |
|---|---|
| Editor Basics | Open the Page Flow editor, navigate the editor and toolbox, use block menus and Help, and save a flow. |
| Choosing Blocks | Select the appropriate block family for Page actions, content, inputs, Forms, Widgets, Database operations, or Cloud Flow calls. |
| Events and Startup | Organize startup logic, respond to events, structure procedures, and handle asynchronous operations. |
| Data and Cloud Flow | Work with permitted Project data, invoke server-side processing, and understand the browser-to-Backend security boundary. |
| Forms and Widgets | Coordinate modal Forms, shared context, Data Tables, and supported Widget behavior. |
| Custom Code | Use JavaScript statements and expressions within Page Flow and understand code validation. |
| Previewing and Troubleshooting | Test flows, diagnose common problems, and verify behavior before publishing. |
Programming References
This section teaches how to plan and implement Page Flow behavior in the Project Editor. For the exact inputs, outputs, options, and behavior of individual blocks and API functions, use the auto-generated Programming Guide references:
- Page Flow Blocks — Detailed reference for the available visual blocks.
- Client API — Reference for the browser-side ioLoop functions available to supported frontend code.
Many Page Flow blocks also provide a direct documentation link through the block's right-click Help action.
Good Practices
- Start from the user interaction. Identify what triggers the behavior, what data it needs, and what result the user should see.
- Keep workflows visible. Use blocks for the main steps and focused custom JavaScript for specialized logic.
- Organize larger flows. Use clear procedures and names for related behavior.
- Handle asynchronous results. Update the interface only after the operation returns the result needed for the next step.
- Separate UI and trusted processing. Use Page Flow for interaction and Backend capabilities for protected rules or credentials.
- Test the full workflow. Verify success, failure, cancellation, empty data, and access-related behavior before publishing.
Common Mistakes
Avoid these patterns:
- Placing all Page behavior into one large Custom Code block when visual blocks would be clearer.
- Expecting Page Flow to reference Page Elements that have not yet been saved in the visual editor.
- Using returned data before an asynchronous operation has completed.
- Assuming that a Form submission automatically refreshes the Page that opened it.
- Treating hidden Buttons, client-side validation, or shared context as authorization checks.
- Testing only the successful path and overlooking failed data or Cloud Flow operations.
- Confusing Save, Preview, and Publish Project as if they were the same operation.
Page Flow is most effective when browser-side interactions, data access, Form and Widget behavior, and trusted Backend processing are coordinated through clear, testable workflows.