Views / Templates

This post is part of my Dev rules of thumb series. In them, I leave you with a poster with a few rules I follow for each concept, which you can print out and scatter around your office, and a brief explanation of what that pattern is about. You can also find a PDF of the poster at the bottom of this post, for better quality printing. However, please remember, a dev rule of thumb is a Principle with broad application that is not intended to be strictly accurate or reliable for every situation.

When we think of a view, we usually relate it to the MVC pattern, created in the late 1970s by Trygve Reenskaug. However that was a long time ago and software development has changed, although mostly the context. Nowadays we create much larger and complex applications than in the late 1970s, and I dare say most of them are web applications, which was not the case at that time. So what we commonly call MVC in web-development nowadays, is not what was originally created by Trygve Reenskaug.

A view, which I personally rather call template, are simple scripts containing a set of UI widgets (labels, form inputs, static text, animations, modals, etc) and the placeholders for a set of data.

These templates are part of the presentation layer, and the set of data that they present is passed on to them by the core of the application, maybe after going through some kind of transformation into a format more convenient to the template, in order to keep the template as simple as possible.

The logic in these templates is minimal, consisting only of presentation logic, ie “send a form when a button is clicked”, “show a confirmation modal before sending a form”, “make a preliminary input validation”, or “show information X, when the state is Y”.

The really important logic, the business logic, should not be in the presentation layer, it should live in the core of the application: the Application and Domain layers.

As the goal of a template is to show data that is passed on to it, it does use data, but it contains/owns no data.

I’ve created a very, very, very simple mechanism to exemplify how template rendering works. In a real production scenario, things can get very complex, with special ways of rendering special types of data, like dates or money, and escaping the data. So we should use libraries specific for this purpose. Nevertheless, for illustration purposes, here it is:

	<?php
	declare(strict_types=1);
	function render(string $templateFilePath, array $args = []): string
	{
	if (!file_exists($templateFilePath)) {
	throw new Exception("Template file '$templateFilePath' does not exist.");
	}
	extract($args); // extract associative array items into local scope variables
	ob_start(); // buffer the output, so we can get it into a variable instead of returning it immediately
	include $templateFilePath;
	$renderedTemplate = ob_get_clean();
	if ($renderedTemplate === false) {
	throw new Exception(
	"An error ocurred while rendering template '$templateFilePath' with data: \n" . print_r($args, true) . "\n"
	);
	}
	return $renderedTemplate;
	}
	$data = [
	'title' => 'Hello world!',
	'content' => 'A very simple template rendering mechanism.',
	];
	echo render(__DIR__ . '/someTemplate.php', $data);
	// Prints out:
	//<div>
	// <h2>Hello world!</h2>
	// <p>A very simple template rendering mechanism.</p>
	//</div>

view raw run.php hosted with ❤ by GitHub

	<div>
	<h2><?php print $title; ?></h2>
	<p><?php print $content; ?></p>
	</div>

view raw someTemplate.php hosted with ❤ by GitHub