9.1 KiB
Templating
A template engine is not necessary with PHP because the language itself can take care of that. But it can make things like escaping values easier. They also make it easier to draw a clear line between your application logic and the template files which should only put your variables into the HTML code.
A good quick read on this is ircmaxell on templating. Please also read this for a different opinion on the topic. Personally I don't have a strong opinion on the topic, so decide yourself which approach works better for you.
For this tutorial we will use a PHP implementation of Mustache. So install
that package before you continue (composer require mustache/mustache).
Another well known alternative would be Twig.
Now please go and have a look at the source code of the engine class. As you can see, the class does not implement an interface.
You could just type hint against the concrete class. But the problem with this approach is that you create tight coupling.
In other words, all your code that uses the engine will be coupled to this mustache package. If you want to change the implementation you have a problem. Maybe you want to switch to Twig, maybe you want to write your own class or you want to add functionality to the engine. You can't do that without going back and changing all your code that is tightly coupled.
What we want is loose coupling. We will type hint against an interface and not a class/implementation. So if you need another implementation, you just implement that interface in your new class and inject the new class instead.
Instead of editing the code of the package we will use the adapter pattern. This sounds a lot more complicated than it is, so just follow along.
First let's define the interface that we want. Remember the interface segregation principle. This means that instead of large interfaces with a lot of methods we want to make each interface as small as possible. A class can implement multiple interfaces if necessary.
So what does our template engine actually need to do? For now we really just need a simple render method. Create a
new folder in your src/ folder with the name Template where you can put all the template related things.
In there create a new interface Renderer.php that looks like this:
<?php declare(strict_types = 1);
namespace Lubian\NoFramework\Template;
interface Renderer
{
/** @param array<string, mixed> $data */
public function render(string $template, array $data = []) : string;
}
Now that this is sorted out, let's create the implementation for mustache. In the same folder, create the file
MustacheRenderer.php with the following content:
<?php declare(strict_types=1);
namespace Lubian\NoFramework\Template;
final class MustacheRenderer implements Renderer
{
public function __construct(private \Mustache_Engine $engine){}
public function render(string $template, array $data = []): string
{
return $this->engine->render($template, $data);
}
}
As you can see the adapter is really simple. While the original class had a lot of methods, our adapter is really simple and only fulfills the interface.
Of course we also have to add a definition in our dependencies.php file because otherwise the container won't know
which implementation he has to inject when you hint for the interface. Add this line:
[
...
\Lubian\NoFramework\Template\Renderer::class => DI\create(\Lubian\NoFramework\Template\MustacheRenderer::class)
->constructor(new Mustache_Engine),
]
Now update the Hello.php class to require an implementation of our renderer interface and use that to render a string using mustache syntax.
final class Hello
{
public function __invoke(
ResponseInterface $response,
Now $now,
Renderer $renderer,
string $name = 'Stranger',
): ResponseInterface {
$body = $response->getBody();
$data = [
'now' => $now()->format('H:i:s'),
'name' => $name,
];
$content = $renderer->render(
'Hello {{name}}, the time is {{now}}!',
$data,
);
$body->write($content);
return $response
->withStatus(200)
->withBody($body);
}
}
Now go check quickly in your browser if everything works. By default Mustache uses a simple string handler. But what we want is template files, so let's go back and change that.
To make this change we need to pass an options array to the Mustache_Engine constructor. So let's go back to the
dependencies.php file and add the following code:
[
...
Mustache_Loader_FilesystemLoader::class => fn() => new Mustache_Loader_FilesystemLoader(__DIR__ . '/../templates', ['extension' => '.html']),
Mustache_Engine::class => fn (Mustache_Loader_FilesystemLoader $MLFsl) => new Mustache_Engine(['loader' => $MLFsl]),
]
We are passing an options array because we want to use the .html extension instead of the default .mustache extension.
Why? Other template languages use a similar syntax and if we ever decide to change to something else then we won't have
to rename all the template files.
To let PHP-DI use its magic for creating our MustacheRenderer class we need to tell it exactly how to wire all the dependencies, therefore I defined how to create the Filesystemloader, on the next line we typehinted that loader in the short closure which acts as a factory method for the Mustache_Engine, as PHP-DI automatically injects the Object we can then use it in the factory.
In your project root folder, create a templates folder. In there, create a file hello.html. The content of the file should look like this:
<h1>Hello World</h1>
Hello {{ name }}
Now you can go back to your Hello action and change the render line to $html = $this->renderer->render('hello', $data);
Navigate to the hello page in your browser to make sure everything works.
One thing that still bothers me is the fact that we have some configuration paths scattered in our dependencies file. We could add a simple valueobject to our code that gives us a typesafe access to our configuration values.
Lets create a 'Settings' class in our './src' Folder:
<?php
declare(strict_types=1);
namespace Lubian\NoFramework;
final class Settings
{
public function __construct(
public readonly string $environment,
public readonly string $templateDir,
public readonly string $templateExtension,
){}
}
I am using a new Feature from PHP 8.1 here called readonly properties to write a small valueobject without the need to write complex getters and setters. The linked article gives a great explanation on how they work.
When creating an instance of the setting class with my project specific values i will use another new feature called named arguments. There is a lot of discussion on the topic of named arguments as some argue it creates unclean and unmaintainable code, but vor simple valueobjects i would argue that they are ok.
here is a small example of creating a settings object using named arguments.
$setting = new Settings(
environment: getenv('ENVIRONMENT') ?: 'dev',
templateDir: getenv('TEMPLATE_DIR') ?: __DIR__ . '/../templates',
templateExtension: getenv('TEMPLATE_EXTENSION') ?: '.html',
);
lets put that code in a file called settings.php in our config folder, and return the settings object from there
Here is my updated dependencies.php with some imports and aliases added for my convenience:
<?php
declare(strict_types=1);
use DI\ContainerBuilder;
use Laminas\Diactoros\Response;
use Laminas\Diactoros\ServerRequestFactory;
use Lubian\NoFramework\Settings;
use Lubian\NoFramework\Template\Mustache;
use Lubian\NoFramework\Template\Renderer;
use Mustache_Engine as ME;
use Mustache_Loader_FilesystemLoader as MLFsl;
use Psr\Http\Message\ResponseInterface;
use Psr\Http\Message\ServerRequestInterface;
use function DI\create;
$builder = new ContainerBuilder();
$builder->addDefinitions([
Settings::class => fn () => require __DIR__ '/settings.php',
ResponseInterface::class => create(Response::class),
ServerRequestInterface::class => fn () => ServerRequestFactory::fromGlobals(),
Renderer::class => fn (ME $me) => new Mustache($me),
MLFsl::class => fn (Settings $s) => new MLFsl($s->templateDir, ['extension' => $s->templateExtension]),
ME::class => fn (MLFsl $MLFsl) => new ME(['loader' => $MLFsl]),
]);
return $builder->build();
And as always, don't forget to commit your changes.