AppML Why It Was Created
AppML was built to let a common, repetitive job - wiring an HTML page to list, add, edit, and delete records - be described in configuration instead of hand-written in code, following a lightweight model/view/controller split.
The Problem: CRUD Pages Repeat Themselves
A large share of ordinary web app work has the same shape: show a table of rows, let a user add a row, let them edit one, let them delete one. Every one of those steps involves the same kind of boilerplate loops and form-building code, differing from page to page mostly in field names and table names rather than in structure.
- Writing a loop to print each database row as HTML
- Writing an insert form that matches the table's columns
- Writing near-identical update and delete handlers for each table
- Keeping the HTML, the SQL, and the field list in sync whenever a column changes
Same list, two ways
<!-- Traditional: a loop hand-written into the page -->
<?php foreach ($employees as $e): ?>
<tr>
<td><?php echo $e['firstname']; ?></td>
<td><?php echo $e['lastname']; ?></td>
</tr>
<?php endforeach; ?>
<!-- AppML: markup describes the shape, appml.js does the looping -->
<tr appml-repeat="records">
<td>{{firstname}}</td>
<td>{{lastname}}</td>
</tr>AppML's answer was to move the 'which fields, which table, which actions' part into a JSON model, and let a small client library, appml.js, handle the repetitive parts - looping over records, building forms, sending the right action to the server - so a page author writes markup with placeholders instead of a full script for every table.
Mapped onto a classic MVC split: the model is the JSON describing the data source, its fields, and its allowed actions; the view is the HTML page with its placeholders and repeat/if bindings; the controller is the PHP or ASP script that actually executes a requested action. Because these layers were separated, a page's look could change without touching the model, and a field could be added to the model without rewriting the server script.
AppML originated as a W3Schools project intended to demonstrate this kind of declarative, configuration-driven CRUD in a small, teachable form. Today it is best understood as a legacy, niche tool rather than an actively growing framework - its value for a learner lies in the pattern it illustrates, not as a recommendation for building new production systems.
