Pages, UX and Client-Side Logic
Pages, widgets and client logic
A page consists of a layout with placeholders and widgets placed inside them. Data widgets - data view, list view, data grid 2, gallery, template grid - need a context: a page parameter, a surrounding widget, or a data source (database retrieve, microflow, nanoflow, association). Widgets below a data view inherit its object; a nested data view needs an association or a data source of its own.
Client-side behaviour is configured, not coded: on-change behaviour (do nothing, refresh, commit), conditional visibility and editability expressions, dynamic classes, and microflow/nanoflow triggers on click. On-change commit is convenient but writes to the database on every change, and it can trip validation rules the user has not yet satisfied.
Traps
- Conditional visibility is evaluated against the current object; if there is no context or the attribute is not in the client cache, the expression can behave unexpectedly. Prefer expressions over attributes already loaded on the page.
- A page parameter holding a non-persistable entity disappears on browser refresh or when the user re-enters via a deep link - pass an identifier and re-retrieve.
- Popup versus full-page layouts, and "show a page" versus "show a message": questions often turn on whether the page needs its own navigation or should sit inside a flow.
- A microflow data source retrieves everything it is told to; a data grid with thousands of rows renders them all unless paging is configured.
Rule of thumb
Give every widget the smallest possible data source: a data view on one object, a list view or data grid on a list with a range. If a page is slow with a large table, the answer is paging plus an indexed database retrieve - not a microflow data source that loads the whole table.