Views & Templates

In Bedrock, views are classes that contain all logic related to the user interface of an application. Like Bedrock controllers, views make use of a nested hierarchy structure to minimize code redundancy and improve maintainability.

Each view class represents a container for a specific part of an application's user interface. All view classes are extended from the base class Bedrock::View which provides some common functionality across all view objects (method implementations, member variables, and docblocks have been omitted for brevity):

abstract class Bedrock_View extends Bedrock { 
 
    public function __construct() {...} 
 
    public function setValue($name, $value, $default = '') {...} 
 
    public function getValue($name) {...} 
 
    public function __set($name, $value) {...} 
 
    public function __get($name) {...} 
 
    public function printValue($name) {...} 
 
    public function setForm($name, $form) {...} 
 
    public function getForm($name) {...} 
 
    public function printRoot($which) {...} 
 
    public static function registerJavascriptTemplate($javascriptTemplate) {...} 
 
    public static function registerJavascriptLibrary($javascriptLibrary) {...} 
 
    public static function importJavascriptTemplates($javascriptTemplates) {...} 
 
    public static function importJavascriptLibraries($javascriptLibraries) {...} 
 
    public static function exportJavascriptTemplates() {...} 
 
    public static function exportJavascriptLibraries() {...} 
 
    public static function isAjaxRequest() {...} 
 
    abstract function render(); 
}

One of the primary roles view objects have is that of an information container for templates. All data that will be displayed in the browser is assigned to view objects from within controllers. There are five methods used to accomplish this. The View::setValue() and View::getValue() methods as well as the __set() and __get() magic methods are used to store and retrieve data within a view object.

The magic methods allow data stored in view objects to be accessed and manipulated like member variables. This is the most common method for storing and retrieving data in view objects. In addition to these methods, View::setValue() and View::getValue() allow for default values to be used when a requested/specified value does not exist.

Consider the many ways a value can be stored:

// Assigns the string "bar" to the value "foo" 
$viewObj->foo = 'bar'; 
 
// The above code is translated to this: 
$viewObj->__set('foo', 'bar'); 
 
// Assigns the string "bar" to the value "foo" 
$viewObj->setValue('foo', 'bar'); 
 
// Sets to "bar" because assigned value is empty. 
$viewObj->setValue('foo', '', 'bar');

As well as the many ways a value can be retrieved:

// Outputs the string "bar" for the value "foo" 
echo $viewObj->foo; 
 
// The above code is translated to this: 
echo $viewObj->__get('foo'); 
 
// Outputs the string "bar" for the value "foo" 
echo $viewObj->getValue('foo'); 
 
// Returns the default 'bar' because 'blah' does not exist. 
echo $viewObj->getValue('blah', 'bar');

Because views represent visual components for an application, they must be rendered in order to be displayed on a page. This is done through a View::render() method that is defined abstractly in the base class. When implementing this method, all code required to produce output to the browser should be executed here. Lets look at a simple example:

class Application_View_Links extends Bedrock_View { 
    /** 
     * <... docblock ...> 
     */ 
    public function __construct() { 
        parent::__construct(); 
    } 
 
    /** 
     * <... docblock ...> 
     */ 
    public function render() { 
        echo '<a href="' . $this->getvalue('link_01') . '">Link 1</a>'; 
        echo '<a href="' . $this->getValue('link_02') . '">Link 2</a>'; 
        echo '<a href="' . $this->getvalue('link_03') . '">Link 3</a>'; 
    } 
}

Then, in a controller method, you could write this:

//... 
 
// Initialize View 
$links = new Application_View_Links(); 
 
// Assign Values 
$links->link_01 = 'http://www.bedrockframework.com/'; 
$links->link_02 = 'http://www.php.net/'; 
$links->link_03 = 'http://www.google.com/'; 
 
// Render View 
$links->render(); 
 
//...

Which would output this to the browser:

<a href="http://www.bedrockframework.com/">Link 1</a> 
<a href="http://www.php.net/">Link 2</a> 
<a href="http://www.google.com/">Link 3</a>

Because views represent everything that is sent to the browser, they also provide support for managing JavaScript code. Bedrock manages JavaScript code in two forms: libraries and templates. Any JavaScript code stored in their own source files (*.js) are considered libraries. Any JavaScript code that is built dynamically or includes PHP code in some form is considered a JavaScript template.

Bedrock templates represent a collection of files that produce a common look and feel for a Bedrock application. A typical template will consist of images, CSS files, and PHP scripts stored in own directory within the application's template root directory (located here by default: ”\application_root\pub\tpl”). In cases where no template is defined, or where a particular component is not supported by the active template, a built-in default template is used to display content.

For more details about the structure of a template and to learn how to develop your own, see the Templates subsection within the Extending Bedrock section.