Editor Basics

Page Flow is edited in a visual programming canvas. You build browser-side behavior by adding blocks from the toolbox, connecting them, configuring their inputs and options, and saving the flow for the current Page or Form.

The Page Editor defines the visible interface. Page Flow defines what happens when that interface starts, receives user input, or interacts with other Project capabilities.

This page explains how to work with the Page Flow editor itself. For guidance on selecting particular blocks, see Choosing Blocks. For exact block inputs, outputs, and behavior, use the Page Flow Blocks reference.

Opening Page Flow

To open Page Flow:

1. Open Pages & Forms in the Project Editor.
2. Open the Page or Form whose behavior you want to configure.
3. In the Page Editor, choose Flow.
4. Work with the blocks in that Page or Form's Page Flow editor.
5. Choose Save when you want to retain the changes.

Each Page or Form has its own Page Flow. Editing one item's flow does not automatically modify the flows of other Pages or Forms.

Flows can work with shared Project resources, such as Code assets, Database tables, queries, and Cloud Flow, when configured to do so. Sharing a resource does not make the Page Flow itself shared.

If your flow needs to reference a recently added Page Element, save the Page Editor's visual changes first so the saved element structure is available to the flow's configuration tools.

Understanding the Editor

The Page Flow editor has three main working areas:

Area	Purpose
Toolbox	Contains available blocks organized by category and provides a Search area for finding blocks.
Canvas	The area where you place, connect, and organize blocks.
Canvas controls	Help you zoom, pan, and search within a larger flow.

A Page Flow can contain several separate groups of connected blocks, such as startup logic, event handlers, and reusable procedures. Keeping those groups organized helps you understand what runs and why.

Statement Blocks and Value Blocks

Blocks connect in different ways depending on their purpose.

Block Role	How It Is Used
Statement block	Performs an operation and can be connected into a sequence of actions.
Value block	Produces a value that is supplied to an input on another block.
Event or startup block	Provides an entry point for behavior that begins when its supported event or lifecycle moment occurs.
Procedure or function block	Organizes logic that can be called from other parts of a flow, where supported.

For example, consider a Page that displays a message when a user selects a Button:

Button interaction
  Set message content
    Value: "Welcome!"

The interaction is the starting point. The content-setting operation is a statement. The message text is the value provided to that operation.

This is a conceptual illustration, not the exact label or syntax of a particular Page Flow block.

Connecting Blocks

A typical editing sequence is:

1. Find a suitable block in the toolbox.
2. Drag it onto the canvas.
3. Connect it to the intended event, statement sequence, or input.
4. Configure its fields, values, or references.
5. Add other blocks to complete the behavior.
6. Review the connections before saving.

A value block must be connected to an input that accepts its value. Statement blocks should be connected in the intended sequence or placed inside the appropriate event or procedure structure.

A block merely being visible in the canvas does not mean it will run. An unattached statement may have no execution path from a startup event, user interaction, or procedure call. When behavior does not run, check its connections and entry point first.

Ordering Operations

Arrange statements in the order that the workflow should perform them, while allowing for blocks whose operations complete asynchronously.

For example, a data-loading workflow may need to:

1. Start the data request.
2. Wait for the result through the block's supported completion or result path.
3. Update the Page when the data is available.
4. Show an appropriate message if the request fails.

Do not assume that an asynchronous data or Cloud Flow operation has finished just because the next statement has started. Use the success, failure, or completion path supported by the particular block.

For lifecycle and asynchronous behavior, see Events and Startup.

Navigating the canvas

The canvas is designed to support both small flows and larger Pages with multiple behaviors.

Common navigation actions include:

Action	When to Use It
Zoom	Inspect a detailed block configuration or view more of a large flow at once.
Pan	Move across different groups of blocks in the canvas.
Canvas Search	Locate content already placed in the current canvas.
Toolbox Search	Find an available block to add to the flow.

Toolbox Search and Canvas Search serve different purposes. Toolbox Search helps you find blocks you can add; Canvas Search helps you locate blocks or content already in the current flow.

When a flow grows, place related event handlers and procedures near each other, and avoid scattering the blocks for one feature across unrelated areas of the canvas.

The Toolbox

The toolbox organizes blocks by purpose. Common categories include:

Category	General Purpose
Flow	Workflow structure and control.
Page Content	Working with Page content and supported content elements.
Style/CSS	Changing supported visual styling or classes.
Input	Reading or working with input controls.
Html/DOM	Working with supported browser document elements and properties.
Page Action	Performing page-level interactions and actions.
Widgets	Coordinating supported Widget behavior.
Data Design	Working with data-driven visual designs and rendering.
Forms	Opening, interacting with, and coordinating Form workflows.
Cloud Flow	Initiating supported Cloud Flow operations.
Database	Working with permitted Project data operations.
Logic	Conditions and logical operations.
Text	Text values and operations.
Lists	Working with collections of values.
Math	Numeric values and calculations.
Objects	Building and working with structured values.
Functions	Organizing reusable logic.
Variables	Storing and reusing values within a flow.
Advanced	Additional supported programming capabilities.

Available blocks and their configuration depend on the selected category and the current editor context.

Finding the Right Block

Start by describing the behavior you need in practical terms, such as:

• When the Page opens, load the initial records.
• When a Button is clicked, open a Form.
• When a selection changes, update a summary.
• When a Form succeeds, refresh the Data Table.
• When a protected operation is required, call Cloud Flow.

Then find the corresponding block family through the toolbox or Search. Use Choosing Blocks for guidance on which family to select.

Do not start with Custom Code simply because the exact block is unfamiliar. Check the toolbox and reference first; a supported block often keeps the workflow easier to inspect and maintain.

Block Help

Many ioLoop blocks provide direct links to their documentation.

To open Help for a supported block:

1. Right-click the block in the canvas.
2. Choose Help, when available.
3. Review its inputs, outputs, behavior, and related reference material.
4. Return to the canvas and configure the block accordingly.

The complete reference starts at Page Flow Blocks.

If a particular block does not offer a Help entry, use the block reference index or documentation search. Not every block has the same context-menu actions.

Right-Clicking a Block

Right-clicking a block opens its contextual action menu. Available actions depend on the block type and state.

Action	Purpose
Clipboard Export	Copies the selected block structure for reuse through compatible Page Flow clipboard import.
Duplicate	Creates a copy of the selected block and attached child blocks.
Add Comment	Adds an explanatory note to the block.
Inline Inputs	Changes the arrangement of supported block inputs.
Collapse Block	Hides internal block details to make the canvas easier to scan.
Disable Block	Keeps the block in the canvas while excluding its behavior.
Delete Block	Removes the selected block from the canvas.
Help	Opens the block's reference documentation when available.

Labels can change with the block's current state. For example, an expanded block can offer Collapse Block, while a collapsed block can offer an expansion action. A disabled block can offer an action to enable it again.

Duplicating Blocks

Use Duplicate when several actions require a similar block configuration.

For example, you might duplicate an existing content-update sequence for a second status message and then change the destination element and message value.

After duplication, review references to Page Elements, Forms, tables, or other resources. A duplicated block may retain settings that were appropriate only for the original use.

Adding Comments

Use Add Comment to record information that is not obvious from the block configuration, such as:

• Why a validation condition exists.
• Which external workflow supplies a value.
• A known dependency on a Page Element or Form.
• Why a particular operation must happen before another.

Prefer concise comments that explain intent or assumptions. Avoid repeating what the block visibly does.

Inline Inputs

Inline Inputs changes the way a supported block's inputs are arranged in the editor.

Inline inputs can make smaller blocks compact. Stacked inputs can make blocks with longer expressions or nested values easier to read.

This changes the editor presentation of the block, not the application behavior it produces.

Collapsing Blocks

Collapse Block reduces the amount of detail visible in the canvas.

Use collapsed blocks when you want to:

• Scan the overall flow structure.
• Reduce clutter in a large group of blocks.
• Focus on one part of a complex workflow.

Expand a block again when you need to review or change its inputs.

Collapsing does not disable execution. It only changes what is visible in the editor.

Disabling Blocks

Disable Block keeps a block in the canvas while excluding it from the generated behavior.

Use this when temporarily testing an alternative or isolating a suspected problem without deleting the original block.

For example, if you are testing a new startup data request, you might disable an older request sequence while retaining it for comparison.

Before saving and previewing, confirm which blocks are enabled. A disabled block may explain why an otherwise correct workflow has no effect.

Do not use disabled blocks as a permanent version-control or backup strategy. For significant changes, use the Project's normal save and checkpoint practices as appropriate.

Deleting Blocks

Delete Block removes the selected block from the canvas.

Before deleting a block or group, consider whether it contains nested statements, values, or logic needed elsewhere in the flow. Review the resulting connections after deletion.

When you only need to temporarily exclude behavior, disabling may be easier to reverse than deletion.

Right-Clicking the Canvas

Right-clicking an empty area of the canvas opens the canvas menu, rather than the menu for an individual block.

Action	Purpose
Clipboard Import	Imports compatible Page Flow block data from the browser clipboard into the current canvas.

This is different from importing Page Elements into the visual Page Editor. Page Flow clipboard operations reuse programming blocks, not visual Page Element layouts.

Reusing Blocks with Clipboard Export and Import

A typical workflow is:

1. Open the Page Flow containing the blocks you want to reuse.
2. Right-click the appropriate block and choose Clipboard Export.
3. Open the destination Page Flow.
4. Right-click an empty area and choose Clipboard Import.
5. Place the imported blocks in the appropriate canvas location.
6. Review their inputs, attached blocks, element references, and other configuration.
7. Connect the imported logic to the correct entry point, then save and preview.

Use compatible ioLoop block clipboard content. Do not assume that ordinary JavaScript text, external HTML, or copied Page Elements can be imported through Clipboard Import.

Browser clipboard permissions may affect these operations.

Important: Imported blocks can still reference elements, Forms, queries, or resources from the original Page or Project. Verify and update those references for the destination before using the imported logic.

Organizing Larger Page Flows

A small Page Flow may need only one startup sequence and a few event handlers. More complex applications benefit from a consistent structure.

A useful conceptual arrangement is:

Startup
  Initialize Page
  Load initial data

User Events
  Handle search
  Open customer Form
  Refresh results

Procedures
  Load customers
  Update summary
  Show error feedback

These labels are examples of organization, not predefined Page Flow block names.

For maintainable flows:

• Keep startup behavior separate from user-triggered behavior.
• Group blocks that support the same feature.
• Use meaningful procedure and variable names.
• Use comments for non-obvious decisions.
• Keep repeated logic in reusable procedures where appropriate.
• Prefer clear blocks for the main workflow over a single large Custom Code block.

For event structure, procedures, and asynchronous behavior, see Events and Startup.

Custom Code and Code Expressions

Page Flow supports visual blocks alongside focused JavaScript.

Block	Appropriate Use
Custom Code	JavaScript statements needed within a Page Flow sequence.
Code Expression	A single JavaScript expression that supplies a value to another block.

A Code Expression is not a place for a sequence of statements. Its editor expects a single expression rather than multiple statements or top-level await.

Use these blocks when they make a focused operation clearer, not as a replacement for the entire visual flow. For larger reusable JavaScript or CSS, consider the frontend Code assets supported by the Project.

For syntax, editor assistance, and validation guidance, see Custom Code.

Saving Page Flow

Choose Save to retain changes made to the current Page Flow.

When you save, ioLoop generates the JavaScript used by the Page or Form's browser-side runtime.

JavaScript Validation During Save

Before saving, ioLoop validates enabled Custom Code and Code Expression blocks.

If either contains invalid JavaScript, the save is stopped and the editor shows an error. Open the affected block, correct the JavaScript, and save again.

Disabled Custom Code or Code Expression blocks are not included in this validation path while they remain disabled.

A successful save establishes that the flow passed the editor's save-time checks; it does not guarantee that every runtime interaction, data operation, or external service call will succeed. Test behavior in Preview.

Unsaved Changes

If you try to leave the Page Flow editor with unsaved changes, ioLoop prompts before discarding them.

Save before closing when you intend to retain your work. If you have been experimenting and do not want the changes, follow the editor's prompt to discard them.

Save, Preview, and Publish

These actions serve different purposes:

Action	Purpose
Save	Retains the edited Page Flow in the Project's development state and generates its runtime JavaScript.
Preview	Lets you test the saved Page and Page Flow behavior in the development context.
Publish Project	Releases the current Project development state to the published application.

Saving Page Flow does not itself publish changes to the live application. Preview the relevant Page or Form, then publish the Project when the changes are ready.

For details, see Previewing and Troubleshooting and Previewing.

Example: Add a Simple Button Interaction

Suppose a Page contains a Button labeled Show Message and a Text element intended to display a response.

1. Prepare the Page

1. Open the Page in the visual Page Editor.
2. Add the Button and the Text element.
3. Give the elements clear names so they are easy to identify in Page Flow.
4. Save the Page content.

2. Build the Flow

1. Open Flow for that Page.
2. Find the supported block or event mechanism for responding to the Button interaction.
3. Configure it to reference the Show Message Button.
4. Add the appropriate Page Content operation to update the Text element.
5. Supply the message as a text value.
6. Connect the blocks into the intended interaction sequence.

Conceptually, the flow is:

When Show Message is selected
  Set Message Text content to "Welcome!"

The example describes the behavior; consult the block reference for the actual block names and inputs available in the editor.

3. Save and Test

1. Save the Page Flow.
2. Return to the Page Editor and open Preview.
3. Select the Button.
4. Verify that the correct Text element is updated.
5. If nothing happens, confirm that the blocks are enabled, connected, and referencing the saved Page Elements.

Once this basic pattern works, you can apply the same editing workflow to richer interactions such as opening modal Forms, refreshing Widgets, rendering Data Design content, or calling Cloud Flow.

Troubleshooting Common Editor Issues

Issue	What to Check
A block does not run	Confirm that it is enabled and connected to the intended entry point or procedure.
A block cannot connect	Check that the block's connection or value type is appropriate for the destination.
A Page Element is missing	Save the visual Page content and confirm the correct element reference.
Imported blocks do not work	Review references copied from the source flow and connect the imported logic appropriately.
Save is rejected	Check enabled Custom Code and Code Expression blocks for JavaScript validation errors.
An operation succeeds in the editor but not in Preview	Check runtime context, data access, asynchronous completion, and required Project configuration.
Changes do not appear in the published Project	Confirm that the Page Flow was saved and the updated Project was published.

For systematic diagnosis, see Previewing and Troubleshooting.

Good Practices

• Save visual Page changes before configuring references. Use the latest saved Page Elements in the flow.
• Start from the behavior. Choose an event or lifecycle entry point, then build the associated operations.
• Keep connections explicit. Ensure statements and values belong to the intended event or procedure.
• Search before improvising. Check the toolbox and block references before replacing supported blocks with custom code.
• Use comments and meaningful names. Make the flow understandable to other Creators and to your future self.
• Use Disable for temporary comparisons. Verify that the intended blocks are enabled again before release.
• Check imported references. Reused block structures may contain Page-specific settings.
• Save and preview regularly. Test changes in manageable increments instead of waiting until a large flow is complete.

Common Mistakes

Avoid these patterns:

• Assuming a block runs simply because it appears on the canvas.
• Connecting an operation to the wrong event or procedure.
• Confusing toolbox Search with canvas Search.
• Treating Collapse Block as if it disabled execution.
• Leaving required behavior disabled after testing.
• Reusing duplicated or imported blocks without updating references.
• Using Clipboard Import for ordinary JavaScript, HTML, or visual Page Element content.
• Putting a large Page Flow into one Custom Code block when blocks could show the main workflow.
• Assuming a successful Save proves that the complete runtime workflow is correct.
• Forgetting that saving development changes is different from publishing the Project.

The Page Flow editor is most effective when it remains readable: start from an event or startup action, assemble the relevant blocks, keep dependencies and references clear, then save and test the behavior in Preview.

Related Topics

• Page Flow
• Choosing Blocks
• Events and Startup
• Custom Code
• Previewing and Troubleshooting
• Editing Page Content
• Page Flow Blocks
• Client API