Page registration
Capsule supports two page models, and most real apps use both. The usual split is simple. Use the Python DSL for dashboards, metrics, settings, tables, and task views. Use React when the page starts to feel like a richer application surface, such as a mailbox, approval queue, or list-detail workflow. Both page types can be public or gated to signed-in users of the deployed app withaccess="authenticated".
Worked example
A strong Capsule app often uses both page models at once:- use the DSL for dashboards, metrics, settings, and task views
- use React for richer list/detail or workflow-heavy surfaces
Python DSL pages
Example:
React pages
Example:
DSL widgets
The Python DSL is deliberately small. You compose a page from a few primitives rather than learning a big UI framework.Layout
Data display
Settings widgets
Task UI
Here is a compact DSL page that uses several of these widgets together:
Widget notes
Metriccan display a literalvalueor bind todataplusfield.Tablecan bind to a collection, a data handler, or inlinerows.Chartbinds to a named data source and supportsline,bar,pie,scatter, andarea.- Passing a
CollectionReftoTable(...)lets Capsule inherit collection metadata automatically.
React page runtime
React pages are built with the@capsule/page runtime. The most common helpers are:
useData(...)useCollection(...)useTheme()useCapsule()for the current app user pluslogin()/logout()
access="authenticated" pages, Capsule handles the sign-in gate before the React page loads. Inside the page, useCapsule().user is the signed-in user for this app. If you want a public page to prompt for sign-in, useCapsule().login() opens the app sign-in flow.
React pages are the right choice when you need custom interactivity or external packages. The Python DSL is usually faster when metrics, tables, charts, and settings widgets are enough.
Naming pitfall
Do not confuse:cpsl.Columnfor collection schemacpsl.ui.Columnfor page layout