Framework Skeleton: Setting STDERR View Resolvers

Error renderers (or view resolvers) are STDERR MVC API components created to implement content-type specific rendering of output based on handled exception.

How do they work?

Each renderer corresponds to a content type and a class implementing Lucinda\MVC\STDERR\ErrorRenderer. Each renderer wraps a Lucinda\MVC\STDERR\Response object that encapsulates data to be used in rendering (headers, view file, output stream). Renderer's job is merely to use that data in constructing an output.

How are they located?

Each view resolver corresponds to a <renderer> tag @ stderr.xml that maps content type to renderer class, identified by "class" attribute. It is allowed to have a renderer without a class, in which case response will be just headers. It will be located on disk as a file whose name equals value of "class" attribute in folder set by <renderers> tag.

How is content type detected?

Framework determines response content type:

What does framework already come with?

Framework skeleton comes with three renderers preinstalled but users can add their own:


This is the simplest view resolver for HTML format. Expects templating logic in view (eg: loading view parts) to be done in PHP and values of response attributes set by controllers to be accessed inside views using $_VIEW pseudo-superglobal.

Example of view body:

<?php require_once("header.php"); ?> Thrown exception was: <?php echo $_VIEW["error_message"]; ?><br/> <?php require_once("footer.php"); ?>

Where value of "hello" was set in controller as:

$this->response->attributes("error_message", $this->request->getException()->getMessage());

1. All view files MUST use HTML extension
2. Response attribute values can be primitives, arrays or objects
3. It is highly discouraged to have anything but procedural logic inside views


Resolves views into HTML format using ViewLanguage templating, which makes it possible for views to be free of PHP and easy to work with through an extension of HTML language. Employs Lucinda\Framework\ViewLanguageBinder and Json models to bind ViewLanguage API with contents of <application> tag. Value of response attributes set by controllers are to be accessed inside views using ${data.{ATTRIBUTE_KEY}}.

Example of view body (equivalent to above):

<import file="header"/> Thrown exception was: ${data.error_message}<br/> <import file="footer"/>

To make it very easy for front end developers to work with, templating logic inside behaves like an extension of HTML supporting:

Documenting how view language works is way beyond the scope of this section and covered in great detail by this article. What it does at its fundamental level is:

  1. aggregating a view recursively from templates and tags (found in folders defined by tags application>paths>views and application>paths>tags @ XML)
  2. checking if aggregation is different from a previous compilation (found in folder defined by application>paths>compilation tag @ XML)
  3. compiling expressions and scriptlets into PHP (if different)
  4. saving PHP compilation into a file waiting to be outputted (if different) or returning existing one (if same)

1. All view files have configurable extension
2. This listener only runs if output is of text/html content type.
3. Response attribute values must be scalars or infinite depth scalar arrays or objects behaving like scalar arrays by implementing ArrayAccess.
4. Output buffer should be clean when this listener starts, which means class attribute value should be empty for <format> tag @ XML that matches text/html.
5. Compilations folder contents may differ based on development environment, thus should be gitignored by developers


Resolves views in JSON format, using Json model. All responses will follow this pattern: