Some pages do not end by reaching their last line: a form handler redirects, a guard refuses, an error stops everything. PAD has a tag or a function for each - and none of them can be demonstrated live on this page, because each one would end the request this page is. The examples are therefore shown, not run.
From a page's PHP, padRedirect() sends the browser to another page and ends
the request cleanly - session closed, buffers flushed, headers sent:
padRedirect ( 'tickets/index' ); // to a page of this application
padRedirect ( 'tickets/index', $vars ); // with variables carried alongNever use PHP's exit or die, and not
header() either: they end PHP mid-request, skipping everything PAD still had to
do. The same goes for a restart - padRestart('page') renders another page in
place of this one without a round trip to the browser.
| tag | what it does |
|---|---|
{exit} | ends the request where it stands - nothing is shipped, not even the output so far |
{error 'message'} | reports an error through the configured error action, which normally ends the request with a 500 |
{exception 'message'} | throws a real PHP exception, for testing the nets that catch one |
{dump} | stops the request on a dump of the engine state, the heavy debugging tool |
Any error - a tag that misses, a PHP warning, a thrown exception - goes to the configured
$padErrorAction: pad renders an error page and ends the request, as
stop, exit and boot end it too - with HTTP 500, and a
command-line run exits with status 1, so a script can test the outcome without reading the
output. log records the error in the log and ignore drops it - with
both the page carries on,
dump writes a dump of the engine state under DATA and carries on - those answer
200 - and php leaves it to PHP's own handling: a warning is printed in the page,
a PAD error is an uncaught exception.
A demand option turns an empty tag into an error: a page that is meaningless
without its data can say so - {users demand}...{/users} -
instead of rendering a hole.