10: Gereedschap & CLI

Phlo-apps hebben een CLI-laag voor build, lint, release en reflection. Gebruik het altijd via de dev entrypoint van de app.

10.1: Bouwopdrachten

php www/app.php build::run
php www/app.php build::lint
php www/app.php build::release
php www/app.php build::config
php www/app.php build::changed

build::lint zou een lege array moeten retourneren:

[]

Als lint fouten rapporteert, corrigeer dan de .phlo bron en bouw opnieuw. Patch nooit de gegenereerde PHP.

10.2: Reflect commando's

Reflectie helpt je een app te begrijpen voordat je deze wijzigt:

php www/app.php reflect::context
php www/app.php reflect::compactRoutes
php www/app.php reflect::compactViews
php www/app.php reflect::resourceSummary
php www/app.php reflect::objectIndex
php www/app.php reflect::functionIndex

Deze commando's retourneren JSON en zijn bedoeld voor ontwikkelomgevingen met build: true.

Dezelfde introspectie stuurt de Graph view van het Phlo Control Center: elke klasse, resource en afhankelijkheidsrand van je app, live weergegeven vanuit reflect::graph:

Volledige referentie:

10.3: General CLI dispatch

build:: and reflect:: are just two examples of a more general mechanism. Phlo's CLI can call any static, method or function in your app:

php www/app.php tasks::run                   # static method on a class
php www/app.php app.heartbeat                # method on a Phlo instance
php www/app.php answer "is an eel a fish"   # global function

Three patterns:

Output goes to stdout as JSON, errors go to stderr with a non-zero exit code. That makes every routine in your app directly usable from cron, deploy scripts, monitoring or a terminal, without building a separate CLI layer for it.

phlo_eval: run Phlo against the live app

The most powerful function dispatch is phlo_eval, which transpiles a string of Phlo and runs it in the live app. It is the runtime complement to reflect::: reflection reads the static source, phlo_eval executes against real data, resources and views.

php www/app.php phlo_eval "user::recordCount()"          # 38, no return keyword
php www/app.php phlo_eval "%app->title"                  # "App"
php www/app.php phlo_eval "echo '<strong>boom</strong>'" # raw HTML, not JSON

A single line auto-returns like a => arrow body, so you write just the expression, no return (unless it starts with return/apply/echo/unset/yield); only a multiline block needs its own return. return prints the value as JSON (type-safe, non-scalar, errors as {"error": ...}); echo prints raw to stdout, handy for viewing rendered markup as-is.

phlo_eval runs arbitrary code with full app privileges: it can read secrets and mutate the database. It is CLI-only and build-only, never present in release/production. Treat its input as developer-authored only, never untrusted.

Only available with build: true in www/app.php. Do not run against a live production environment.

10.4: Debug helpers

Met debug: true in phlo_app(...) activeert Phlo een set helpers voor inspectie tijdens de ontwikkeling. In productie zijn ze inactief.

De levenscyclus: helpers verzamelen tijdens het verzoek (%res->dump, %res->debug); aan het einde van een sync-pagina logt een inline script alles naar de browserconsole samen met geheugen-, duur- en trace-metadata, en async-responsen dragen dezelfde gegevens in hun apply payload. Objecten worden uitgepakt via objInfo(). Runtimefouten worden verzameld in data/errors.json (bericht, source-mapped bestand en regel, aantal, laatste optreden); lees ze met reflect::errors of in het Phlo Control Center.

method buildReport {
	$data = $this->load
	debug('loaded', count: count($data))
	if (!$data) error('No data to report')
	dx($data[0])
}

dx() is je primaire "stop en kijk naar wat er is" tool tijdens de ontwikkeling. Vergeet je een dx() in de code die naar release gaat? In debug: false modus gedraagt het zich net als error(), zonder stille doorgang.

10.5: Workflow

In een ontwikkelomgeving plaatst het Phlo Control Center (op /phlo) deze hele lus in de browser: source, build, release en fouten, met elk bestand één klik verwijderd:

1. Lees eerst de source en de reflection output.
2. Wijzig alleen .phlo, data/app.json of entrypoints.
3. Voer build::run uit.
4. Voer build::lint uit.
5. Test de relevante HTTP routes.
6. Voer build::release uit wanneer de stage/release output moet worden bijgewerkt.

10.6: Ontwikkeling, staging en productie

Dev heeft doorgaans:

auth: true,
build: true,
debug: true,

In build+debug-modus bevindt de ingebouwde controle-UI zich standaard op /phlo; gebruik control: 'path' in phlo_app(...) om een ander pad te kiezen. Staging/productie draait doorgaans zonder build en zonder debug. De webroot wijst naar release/www/.

10.7: HEAD and async

The current runtime supports the normal HTTP methods, including HEAD. Async requests are handled by the frontend resource and use the same routes as sync requests, unless you explicitly declare a route otherwise.

Reference. The core resources are documented per node in the Manual, generated from the resource files so it never drifts from the code.

Laatst bijgewerkt op 23-08-2026