AppML How It Works
AppML follows a fixed request flow: the browser loads the page, appml.js reads the appml-data attribute, fetches the model, the model's action reaches the data source, and the result is bound into the template.
The Request Flow, Step by Step
- The browser loads an HTML page that includes appml.js and contains an element with an appml-data attribute.
- appml.js scans the page, finds that attribute, and reads the filename it points to - the model.
- appml.js requests the model, a JSON file describing the data source (for example a database table) and the actions available on it.
- By default the model's list action runs, which reaches into the data source and gathers the requested rows.
- The action's result comes back to the browser as JSON.
- appml.js walks the template, repeating any appml-repeat blocks once per row and substituting {{fieldname}} placeholders with values from the result.
None of this requires a page reload. The model reference, the action name, and the returned JSON are the only moving parts - the template stays static markup until AppML rewrites the pieces marked with its attributes.
Example
<div appml-data="model.json">
<div appml-repeat="employees">
<p>{{firstname}} {{lastname}}</p>
</div>
</div>
<!-- model.json -->
{
"database": "companydata",
"table": "employees",
"actions": [
{ "name": "list", "sql": "select * from employees" }
]
}A model file is not the data itself - it's configuration. It names the data source (in this example a database and table) and defines one or more actions, each one a named operation the model is willing to perform, such as list, insert, update, or delete.
Where Actions Fit In
Each action in the model maps to real logic on the server: a query to run, a row to insert, or a record to update or remove. The browser never talks to the database directly - it only ever asks a named action on a model to do so, which keeps the data access logic in one predictable place. Controllers and Actions covers this mapping in depth.
