Templating System

This information is intended to describe how phpMyForum's templating system works. This document is not intended to be a guide with which you can create your own templates, a separate tutorial will be published for this purpose.

Why A Templating System

PHP Itself is a templating system. You create PHP scripts that perform execution and send output to the browser. These scripts can be described as dynamic templates for web pages. For phpMyForum, since we are providing a backend rather than a frontend, a method of getting data from the back end to the front end (be in part of some further server side process such as a script, or directly to a browser) is necessary. So how do we not dictate how the output will work, whilst getting the output, erm, out? We rely on a set of PHP templates, that's how.

What We Need / Want

There are two primary avenues to explore in how we define what a template must consist of. One is usability: if no-one can quickly learn and build their templates, they certainly will not use our software. Imagine a mobile phone without number keys for 6, 7, and 8; useless for most calls. Second, it must be usable from a systems logic perspective: if we cannot communicate or use the template from our code or they are difficult to manage or slow, then we will quite rightly be subject of much criticism and complaints.

So with this in mind, what should a template consist of to be usable (from programmer and systems perspective)? We need:

• output of a full message
• output of a forum's name, description, parent and children
• output of what messages (subject) are available in the forum (perhaps restrictive in a public view (think: moderation))
• variations upon these themes for other purpose (think: front page, first line of the latest forum message posted)

We can from here see that the templates may be split into purposes. We'll refer to these templates as 'views' from here on since the templates are literally a view on our objects' data.

The views above should be considered a common arrangement. The fact is, people will want/need to customise the views according to their own desires. They will want views that fit nicely in to their site's layout and colour scheme so that a fluent look and feel is apparent to the visitor. For this reason the content of each view file much be editable. Plain text content, then.

Hm, plain text, editible, customisable. We are built in PHP. Why not make the views PHP code themselves? After all, if we introduce our own method for looking up bits of data and processing them through views, we're adding a learning curve, a lot of bugs and time, and potentially losing a vast audience. When you download the phpMyForum package you are told it is designed to be integrated within your own website using a published API, thus it is safe to assume you know PHP well enough to customise the PHP views.

Making Views

A view will consist of forum data. Since it must be fully customisable, we must have everything the view might want ready and prepared in the PHP object containing the view. For example, the forum object will contain a view of the forum, and perhaps a set of messages. If we want to show a message, the forum's message view will be called and handed the data of the forum the message is in, and the message itself. All the applicable data must be accessible to be fully customisable.

Thought: We could readfile() the view file in, process the PHP inside the view to evaluate all the strings for, say, message subject, body, dates and poster, then output it to the client.

Okay, so what should a view look like in terms of PHP? In essence nothing major. It shouldn't have functions in, unless the developer building his own views decides he wants them. Straightforward PHP outputting HTML/XML together with the forum/message data available to it. An example perhaps:

<table class="message">
<tr><td class="subject">
<?php echo $vars["subject"] ?>
</td></tr>
<tr><td class="message-body">
<?php echo $vars["body"] ?>
</td></tr>
<tr><td>
<input type="submit" name="reply" value="Reply" /> | <input type="submit" name="back" value="Go Back" />
</td></tr>
</table>

This provides the 'view' for a basic message. Store this code in a file, load it from our viewer function in the forum object, passing it the $vars array holding the data, and bingo.

We should store these views as 'ViewPacks' such that they may be collected and distributed for others to use. Also, each view should be placed on disk in such a way that multiple languages are supported. Perhaps a set of views in a directory en/ for English, de/ for German, etc.