AppML PHP Backend

PHP as the Action Handler

When a model's list, insert, update, or delete action needs to touch a real database, the model points at a PHP file. AppML's client library sends the current action and any submitted field values to that file, and the PHP script is responsible for running the right SQL and sending a JSON response back to the page.

• Read which action was requested
• Connect to the database
• Run the corresponding query - select, insert, update, or delete - using the submitted field values
• Encode the result as JSON before printing it back to the client

<?php
header('Content-Type: application/json');

$action = $_GET['action'];
$conn = new mysqli('localhost', 'appml_user', 'secret', 'hyring_learn');

switch ($action) {
  case 'list':
    $result = $conn->query('SELECT id, firstname, lastname, department FROM employees ORDER BY lastname');
    $records = array();
    while ($row = $result->fetch_assoc()) {
      $records[] = $row;
    }
    echo json_encode(array('records' => $records));
    break;

  case 'insert':
    $stmt = $conn->prepare('INSERT INTO employees (firstname, lastname, department) VALUES (?, ?, ?)');
    $stmt->bind_param('sss', $_POST['firstname'], $_POST['lastname'], $_POST['department']);
    $stmt->execute();
    echo json_encode(array('success' => true));
    break;

  default:
    echo json_encode(array('error' => 'Unknown action'));
}
?>

The client expects a specific JSON shape back - for example, an object with a records array for a list action. The PHP script must set its content type to application/json and produce a response that matches what the page's bindings expect, or the placeholders on the page will have nothing to resolve against.

PHP was a natural fit for this role historically because of how widely it was supported on shared hosting. An AppML PHP handler is just an ordinary PHP script - there is nothing framework-specific about it, and it can be read, edited, or debugged like any other page.