AppML Architecture Overview

AppML's architecture has three moving parts: a client-side library that reads placeholders and bindings, a JSON model describing the data and allowed actions, and a server-side action handler (PHP or ASP) that actually talks to the database.

Three Pieces, One Round Trip

A single user action - say, loading a list or submitting an insert form - passes through all three layers in turn: the page's client library, the model that describes the data, and, when real persistence is needed, a server-side handler that executes the action.

  • The page loads and includes appml.js
  • appml.js reads the page's model reference and requests the current action's data
  • The model identifies the fields available and which action is being requested
  • appml.js renders {{placeholders}}, appml-repeat, and appml-if against the records it receives
  • User interactions such as insert, update, or delete are sent back through the model to the server handler, and the response is rendered the same way

Client library include

<html>
<head>
  <script src="appml.js"></script>
</head>
<body appml-data="employees.json">
  <div appml-repeat="records">
    {{firstname}} {{lastname}}
  </div>
</body>
</html>
LayerResponsibility
Client library (appml.js)Parses placeholders and bindings, renders records, sends actions
Model (JSON)Names the data source, lists fields, declares allowed actions
Server handler (PHP/ASP)Executes the requested action against the real data store and replies with JSON

Because these layers are separated, the same client library and the same page markup can sit in front of either a PHP handler or an ASP handler. The page doesn't know or care which server-side language is behind the model - only that it responds to the same actions in the same JSON shape.

Note: Because everything the client renders comes from matching {{placeholders}} against whatever JSON the server returns, the fastest way to debug a blank or broken binding is to look at the raw JSON response first, before touching the markup.

For prototyping, the server-handler layer can be dropped entirely in favor of a static file, which underlines the point: the architecture's three parts are independently replaceable, not tightly welded together.

Where State Lives

The actual records live only in the real data source behind the server handler. The client library holds only the current page's rendered copy of that data, so a second browser tab, or a page reload, always re-fetches through the model rather than assuming a cached client-side copy is still current.

Exercise: AppML History and Architecture

How does AppML's real-world adoption compare to frameworks like React or Angular?