1. What RTO is for

RTO is a design pattern for web artefacts: sites, landing pages, blogs, newsletters and small apps. It is not for applications in general.

The difference matters. A website is a collection of information presented in various ways; an application is a tool that does something. A website has a sitemap, and an application doesn’t. RTO is built around that fact: the page is the unit. You can list the pages of an artefact before building it, and most people who visit only read.

RTO grew out of MVC, but reverses who decides. In MVC a controller decides what data a view receives. In RTO the template declares what it needs, and pulls it.

2. The three steps

1. A request names a resource and a format.
2. The request is mapped to a template.
3. The template is mapped to objects, which return data.

A single envelope (one front controller) does the mapping, runs the objects the template points to, and returns the response. There are no per-page controllers.

2.1 The request

A request is a key-value pair: the URL describes the data, and the format is how to present it. /news is the news in HTML. /news.rss is the same news as RSS. /news/news_page/2 is the second page of it.

The URL is a small query language written as a path. An RTO implementation defines its grammar. Raster’s is:

What the grammar can’t express (joins, references between records) belongs in objects, not in templates.

2.2 The template

A template is the page as it will look: real markup with real content in it. It must render in a browser as a static file, so a designer can open it as a mock-up and an agent can check it by looking.

The dynamic parts are marked with a small, closed vocabulary of annotations that point at objects. In Raster these are HTML comments:

• print.object.method: replace this block with a value.
• render.object.method: repeat this block for each row.
• remove: mock-up content, always removed.
• res and dry: define a fragment and reuse it.

Templates contain no general-purpose logic. The vocabulary is fixed. Anything more (conditions, formatting, access rules) is an object’s job. A closed vocabulary is what makes templates checkable: a tool can list every object a template needs, find every mistake, and derive what data it will store.

2.3 Objects

Objects wrap the logic that fetches and changes data: databases, files, sessions, mail, other services. They return plain data: strings for single values, lists of rows for repeated blocks, and false for “keep what the template has”.

3. Rules the pattern depends on

3.1 The template owns the text. Every word a person reads is in a template: headings, error messages, confirmations, translations, emails. Objects decide whether a block shows and which data fills it, but never write prose. An error message is a block in the template that an object reveals. An email is a template rendered for one recipient.

3.2 The markup is the schema. A template that points at stored content declares that content: its name, its place and its default (the mock-up text). An implementation can derive the storage from the templates. It must be able to report the difference between what the templates declare and what is stored.

3.3 Inner blocks are evaluated first. When blocks nest, the inner ones run before the block around them. A form’s validation messages therefore run before the object that handles the form, and that object already knows the result.

3.4 Writes go through the template. A form posts to the page it is on. The object that renders the form also handles the post. When the post is invalid, the object shows the form again with the submitted values. When it succeeds, the object redirects back to the same page with a marker naming the outcome, and the template shows the matching message. There is no separate write endpoint or controller.

3.5 Constraints live in the markup. A form’s inputs already describe what they accept (required, type, lengths, ranges, patterns). The server enforces the same constraints, so they are written once.

3.6 Formats are templates. A feed, a sitemap or a JSON document is a template in that format, pointing at the same objects. Values are escaped for the format. An email is a template too.

3.7 Fail softly for visitors, loudly for authors. At runtime, a missing object or empty data leaves the template’s own content in place: a visitor sees a stale sentence rather than an error. While building, the same mistakes are errors: unknown objects, unclosed blocks, forms nothing handles, messages nothing reveals. An implementation should provide both behaviours.

3.8 Extension through events. The envelope announces the steps of a request (route found, before render, before output). Objects can subscribe to them for cross-cutting work such as access control, caching and instrumentation, without changing templates.

4. Caching

Because templates declare their data and content changes go through known objects, whole pages can be cached for anonymous readers. The cache is thrown away whenever content changes. Requests with a session or a query are not cached.

5. Standard objects

The pattern doesn’t require them. An implementation should still offer these, following the rules above: every one of them is written in templates, with text owned by the template.

6. Agents

RTO suits artefacts made by software agents because the template is both the design and the contract:

• An agent writes real HTML with real content, which it is good at, and annotates it.
• A checker reports every mistake with its position (3.7).
• The content model is derived, not designed (3.2), so a site can describe itself. Its pages, fields and collections can be exposed as tools, and an agent can edit content without editing code.

7. Where RTO stops

RTO is the wrong pattern when:

• the data model would be drawn before the pages;
• content has references between records and is reused away from its pages;
• the artefact is mostly interaction: multi-step flows, dashboards, state that lives across requests.

In those cases, write objects that do the work, or use a framework built for applications.

How it works

A request picks a view, which is a plain HTML file. The parts of the page that change are HTML comments that name a model and a method:

<h1><!-- print.cms.headline -->Good coffee, slow mornings.<!-- /print.cms.headline --></h1>

<!-- render.cms.menu('order=name') -->
<article>
  <h2><!-- print.name -->Flat white<!-- /print.name --></h2>
  <p><!-- print.price -->14<!-- /print.price --> lei</p>
</article>
<!-- /render.cms.menu('order=name') -->

The view still opens in a browser as a mock-up. When Raster serves it, each annotation pulls its data from the model it names. The template owns all the text on the page, including error messages and emails; models only decide what shows.

What the markup gives you

• A CMS with no schema files. print.cms.headline declares an editable field on that page, and render.cms.menu declares a collection whose fields are the keys inside it. Items get slugs, drafts, scheduled publishing, ordering, filters, pagination and their own URLs. Editors change content in the page, and every save is a new revision.
• Forms with their rules in the HTML. required, type, minlength, pattern and the rest are enforced on the server too, and every message is written in the template. Posts from other sites and bots are refused.
• Accounts and a newsletter, with every screen written in your templates: sign-up, login, password reset, roles, protected pages, double opt-in and sending any page as an issue.
• Feeds and data views. news.rss, sitemap.xml or feed.json are views too, escaped for their format.
• Events between models. When a booking should subscribe the guest to the newsletter, one model sends an event and the other listens. The template never has to know.
• A page cache, translations, mail over SMTP, and a JSON API for every model.

Made for agents too

Raster is built so an AI agent can make and run a site as easily as a person:

• AGENTS.md is the complete specification, in one file.
• raster lint checks every view, form, alert, event binding and query, and a broken template in development shows a list of what is wrong instead of half a page.
• raster schema shows the content model the templates define, compared with the database.
• An MCP server lets an agent read and edit the content, limited to the fields the templates declare.
• raster doctor says whether a site is healthy, up to date and ready for production.

Compared with the big frameworks

Raster is small: one controller, one view file per URL, no build step and SQLite by default. It does less than Laravel or Symfony on purpose. What it generates is easy to follow, pages are fast and cached for visitors, and every page is editable as soon as it exists.

Getting started shows how to make a site with it.

A new site

git clone https://github.com/draganescu/rasterPHP
php rasterPHP/bin/raster new mysite
cd mysite
php bin/raster serve          # http://localhost:8000

raster new copies the framework and a starter app into mysite/. Your site lives in application/:

application/
  config/the_app.php          settings
  models/<name>/<name>.php    your models
  views/<theme>/              views (.html, .rss, .xml, .json), css, images
  data/                       the SQLite database, cache and logged mail

/about renders views/<theme>/about.html, and /docs/setup renders docs/setup.html. Start from static HTML with real content, then mark the parts that change.

Editing it

php bin/raster user you@example.com --role=editor   # log in at /login to edit in the page
php bin/raster lint                                 # after every template change
php bin/raster schema                               # what the CMS will store
php bin/raster render /about                        # a page's HTML, without a server

An agent can do all of this too. AGENTS.md in the site is the full specification, CLAUDE.md points agents at it, and .mcp.json sets up the MCP server that lets them edit the content.

The demo café is a complete site that uses every feature, with a test for each one. When you wonder how something is written, look there.

Putting it online

Any PHP host with Apache (the .htaccess is included) or a server that sends every request to index.php works. On the server:

export RASTER_ENV=production
export RASTER_URL=https://example.com/
php bin/raster schema --apply     # create the tables the templates need
php bin/raster doctor             # anything missing before going live?

Production freezes the database schema, caches pages for visitors and sends mail with PHP’s mail(), or over SMTP when you set RASTER_MAIL.

Keeping it up to date

php bin/raster update             # the latest release
php bin/raster doctor

update replaces only the framework files (system/, bin/raster, index.php, .htaccess and AGENTS.md), refuses if you edited them, keeps the old ones in a backup, and then runs the upgrade steps your app needs. Changes you want in the framework go in your app instead, as overrides; the changelog lists what each release changes.

Earlier versions

Raster started as Spartan PHP, with ports to CodeIgniter and WordPress and a Node.js version planned. Those are no longer maintained. Raster 2, from 2026, is the PHP framework described here.

Raster is a PHP framework for websites, not for web apps. Its idea is small: the view is plain HTML, and the parts that change are HTML comments. The comments don’t break the layout or remove the dummy content, so the same file is both the mock-up and the working page. The pattern behind it is RTO: the request picks a template, and the template pulls its data from objects.

A view and a model

<html>
  <body>
    <h1>A list of things</h1>
    <!-- render.tasks.all -->
    <p><!-- print.task_name -->Lorem ipsum<!-- /print.task_name --></p>
    <!-- /render.tasks.all -->
  </body>
</html>

render.tasks.all loads a plain PHP class named tasks and repeats the block once for each row its all method returns:

<?php // application/models/tasks/tasks.php
class tasks {
    function all() {
        return array(
            array('task_name' => 'Walk the dog'),
            array('task_name' => 'Fill in the groceries list'),
            array('task_name' => 'Convince people to use Raster'),
        );
    }
}

The page then lists the three tasks, and “Lorem ipsum” is gone. Models only return data; the view decides how it looks, and every word on the page stays in the template.

The rest, all optional

• A CMS from the markup. Write <!-- print.cms.headline -->Hello<!-- /print.cms.headline --> and the headline is editable on that page. Use render.cms.news instead of your own model and you get a collection with its own URLs, drafts, scheduled posts and pagination. There are no schema files: the templates are the schema.
• Forms. The rules are the HTML attributes you already write (required, type="email", maxlength), checked on the server too. The error messages are blocks in the template that show when a rule fails.
• Accounts, a newsletter, feeds, translations, a page cache and mail, as bundled models that follow the same rule: your templates hold every screen and every email.
• Events. Models tell each other what happened (event::dispatch('reservation.booked', …)) and listen with a listens() method, so the view never wires models together.
• SQL in files. models/tasks/sql/due_today.sql runs as database::instance()->due_today().
• An API. Every public method of your models is also JSON at /api/<model>/<method>.

Why now

The comments-in-HTML idea turns out to suit agents as well as designers. An agent can write a view as ordinary HTML, check it with raster lint, see the content model it created with raster schema, and edit content through the MCP server. AGENTS.md is the whole specification in one file, and the demo café uses every feature, with a test for each.

Raster is not trying to replace Laravel. It is for the many projects that would be crushed under a full framework: a site, a blog, a newsletter, a landing page, a small app.

Get started, or read the code at github.com/draganescu/rasterPHP.