For the complete documentation index, see llms.txt. This page is also available as Markdown.

App pages

What are app pages?

Apps consist of pages. Pages are made up of components like images, text, forms, tables, and charts. You edit the page in the Page Builder Canvas.

View an app's pages

Every app's info page will contain a Pages section where all the pages for that app will be listed. Each app you create will automatically have a home page, which is fully customizable.

Click ... next to each page name to expose its additional actions menu.

  • Page Settings - Edit the page's title and path.

  • Edit - View the page in the App Builder and edit and update the page's structure and contents as desired.

  • Publish - Publish the page so that it becomes live on your live app. If you've yet to publish your app overall, this won't publish the app. To make the app itself live, open the app and click Publish App on its info page.

  • Compare Draft vs Published - Compare your in-progress draft against what is live in your app right now.

  • Revert Draft - Discard the most recent draft and resets the page to what is currently published.

  • Duplicate Page - Create an exact duplicate of this existing page.

  • Delete - Delete the page entirely. Deleted pages can't be recovered. Exercise caution.

The columns in the page list detail information about each page.

  • Title - This is the active title name of the page.

  • Path - This can be set to customize the end of the URL for the page.

  • Draft Changes - This timestamp represents the last time the page was changed, even if those changes have not yet been published.

  • Published - This timestamp and version stamp represents the last time the page was published, and indicates if it is live in a specific version of the app.

  • Status - The color-coded label indicates if the page is up-to-date or if there is an available draft beyond what your current version uses.

  • Actions - Click ... to reveal more options.

Screenshot of the App Builder page for the app “mymeowtest2” in Rewst, showing a dark-themed interface with a left navigation menu, the app domain link, tabs for Pages, App Settings, and Custom Components, and a Pages table listing page names, paths, update details, and action controls.
An example of the pages list inside an app in App Builder

Create a new app page

  1. Navigate to the newly created app by clicking on it in your Apps list. Every app's info page will contain a Pages section where all pages for that app will be listed. Each app you create will have a home page by default, added by Rewst. Note that you can only have one home page per app.

  1. Click New Page. Give your page a name. Remember that Rewst will create the path, or url slug, for that page based off this name. Choose something that makes sense, but is appropriate to be seen by the eventual audience of the page.

  2. Click Create Page. This will automatically open the new page in the Page Builder.

View and edit pages in an app

  1. Navigate to Apps in the left side menu of your Rewst platform.

  2. Click on the app you wish to work on in your total app list.

  3. The screen that appears is the info page for that app. It contains a list of all pages within the app.

  4. Click the title of your desired page to open it in the App Builder. The Page Builder Canvas is where you can add, edit, and remove components for that page.

An example of the Page Builder for an app

Preview an app page

Before you publish your app, use the Preview feature to see what it would look like live as a page or as a PDF if you plan to use the PDF Export block. Use the settings on the right side of the preview window to change the PDF's appearance.

Delete a page

  1. Navigate to Apps in the left side menu of your Rewst platform.

  2. Click on the app from the list to view your app details.

  3. Click ... next to the page you want to delete.

  4. Click Delete.

Binding in apps

Binding is how you tell a spot on your page "get your content from the data instead of from what I typed." Think of a mail-merge letter. You write "Dear ‹First Name›, your invoice for ‹Amount› is due ‹Date›" once, and the mail merge fills in the blanks differently for every customer. Binding is that, but for an app page. You design the page once with blanks, and Rewst fills the blanks in from real data every time someone opens it. When the Rewst Agent designs and builds your apps for you, it takes care of all the needed binding to meet your request.

Without binding, everything on your page is frozen as whatever you typed while designing it.

With binding:

  • The page shows what's true right now, not what was true when you built it.

  • Nobody has to go edit the page when the data changes.

  • A single "Ticket Details" page works for all 4,000 tickets, because the blanks fill in from whichever ticket the user clicked.

  • When the data behind the page changes — someone picks a different customer in a dropdown, or hits refresh — every bound blank on the page updates itself automatically. You don't wire that up; it just happens.

How block binding works

Add binding to blocks via the Properties tab of a specific block in the Page Builder.

1. Data arrives. Something feeds the page. Usually that's a data source, a workflow that goes and fetches real records and hands the results to the page. It can also just be sample data you type in while you're still designing.

2. The data sits in the page's memory. Rewst calls this CTX. Picture it as a labeled tray sitting behind the page. If your workflow returns a count of open tickets, it might land in the tray at a spot labeled metrics.openTickets. That label is called a path: it's just an address, like a cell reference in a spreadsheet.

3. Elements point at addresses. You select a text block and tell it: your content is metrics.openTickets. That's the binding. Now the block displays 112, and tomorrow it displays whatever the number is tomorrow.

Binding in the Page Builder Canvas

You select the block, then point it at a path. Behind the scenes Rewst writes a small attribute onto that element:

What you want
What the page is really doing

Show a value as text

data-binding-text

Show or hide something depending on the data

data-binding-visible

Fill in an image

data-binding-src

Point a link somewhere

data-binding-href

Fill a dropdown's choices

data-binding-options

Let the user type into a field and capture it

data-model

Add CSS class from data

data-binding-class

Input value

data-binding-value

List items

data-binding-items

The display formatter

data-binding-format

Troubleshoot app binding errors

  • Bind to one simple value, not a whole record. Point at the person's name, not the person. If you bind text to a whole record, you get an empty spot on the page instead of a name. Records go into tables or repeating lists; single values go into text.

  • Bindings can't do math or if-then logic. A binding is an address, not a formula. You can't write "show the total times 1.08" or "show the name, or 'Unknown' if it's blank." If you need a calculation, a percentage, a combined label, or a fallback value, the workflow does that work first and hands the finished value to the page. The binding just displays it. This trips people up because it feels like a spreadsheet cell — it isn't; it's more like the mail-merge blank, which can only hold what you fed it.

  • The address has to actually exist. If you bind to a path and nothing lives there, you get an empty spot or a - on the page. This is the single most common cause of "why is my dashboard blank?" Confirm that the workflow really returns what you think it does before wiring the page to it. You can format without breaking that rule, though — there's a display formatter that adds a $, a %, decimal places, or a date format on top of a bound number. It changes how the value looks, not what it is.

Last updated

Was this helpful?