Framework Skeleton: Setting STDOUT View Resolvers

Page view resolvers are STDOUT MVC API components created to implement content-type specific rendering of output based on handled request.

How do they work?

Each resolver corresponds to a content type and a class extending Lucinda\MVC\STDOUT\ViewResolver. Latter gives it access to compiled Lucinda\MVC\STDOUT\Application and Lucinda\MVC\STDOUT\Response objects necessary for output process. Rendered output is a combination of:

How are they located?

Each view resolver corresponds to a <format> tag @ stdout.xml that maps content type to resolver class, identified by "class" attribute. It is allowed to have a resolver 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 <resolvers> tag.

How is content type detected?

Content type is detected based on requested route: either implicitly by value of "default_format" attribute of <application> tag or explicitly by value of "extension" attribute @ matching <route> tag (necessary if a route expects different output format than application default, for example json instead of html). Both point to a format that must match value of a "name" attribute of <format> tag. Once a format tag was located, content type header will be compiled from value of attributes content_type and charset.

How is response HTTP status set?

Response status is 200 OK by default but can be changed by controllers or event listeners using:


Where is response body taken from?

Response body is compiled either from:

What does framework already come with?

Framework skeleton comes with three view resolvers 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"); ?> Today's greeting is: <?php echo $_VIEW["hello"]; ?><br/> <?php require_once("footer.php"); ?>

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

$this->response->attributes("hello", "world");

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"/> Today\'s greeting is: ${data.hello} <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: