Screens
An app is made up of one or more screens. Each screen has a URL path and a minimum role required to access it.
Adding a screen
When adding a screen you can choose between a blank screen and an autogenerated one.
Blank screen
You'll be prompted for a path for the new screen (for example /customers).
Capital letters and spaces aren't allowed — they're automatically converted to
lowercase and hyphens as you type. A blank screen gives you an empty canvas to build
on.
Autogenerated screen
An autogenerated screen is built from a table's data. SuperToolMake reads the table and generates a screen for viewing and managing those rows, including side panels for creating and editing records. When generating, you select one or more data sources and choose how rows should be managed.
This is the fastest way to get a working CRUD interface over a SQL table.
Screen access
Each screen has an access role. Only users whose role meets or exceeds the screen's role can open it. The screens panel shows a coloured indicator for each screen's role, so you can see at a glance who can access what. See Roles for how roles work.
Screen settings
Select a screen to configure:
- Its URL path.
- Its access role.
- Whether it's the app's home screen.
- URL parameters — see below.
URL parameters
A screen's path can include URL parameters: dynamic segments marked with a colon,
such as :id in /customers/:id. They let a single screen show different data
depending on the URL — for example one "customer detail" screen that works for any
customer.
Define a parameter by adding it to the screen's path:
/customers/:id
Read the parameter anywhere bindings are accepted using the URL binding category:
{{ URL.id }}
A common pattern is a list-and-detail flow:
- A list screen shows rows in a Table or Repeater.
- A Link or navigation action
sends the user to
/customers/:id, passing the selected row's id. - The detail screen binds a Data Provider (or Single Row Provider) to
{{ URL.id }}to fetch and display that specific record.