PHP Framework III: Page Construction

In the previous part of my little PHP framework walkthrough, I covered how an url was turned into a page controller being instantiated. Now I'll describe how the page gets constructed and turned into HTML. The main steps in this process are (starting from where we left off):

1. The show method on the controller gets called with any supplied parameters.
2. The controller retrieves the model of the page to be shown.
3. The controller uses the model to create a view of the page.
4. The view is used to create a page object, which can be customized as needed for the page (This step only applies if the page is an ordinary HTML page).
5. The page source is sent to the client.

The show method handles all the steps involved in constructing the requested page. While the process differs somewhat depending on the page to be shown the above steps describe the typical case.

The first task when constructing the page is to retrieve its model. This model is the model-part of the MVC pattern used by the framework to separate data, presentation and control logic. The model contains information which is to be presented on the website. This could include such information as blog posts, news items or user-generated content, all of which is normally stored in a database. The model class is named similarly as the controller class only it is stored in the model directory instead. The job of the model class is to create a PHP object representation of the data to be shown.

So far the show method in the controller could look something like this:

1. public function show($param){
2.    $posts = MainModel::read();
3. }

The next step is to create a view of the page which is the main content that the client will receive. Similar to the model, there is a view class which is used to generate the code to send to the client, usually HTML. The view class extends a class called Template which just specifies a member called html and a method, get, to retrieve it.

1. class MainView extends Template{
2.     public function MainView($posts){
3.         $html = Header::create();
4.         $html .= MainContent::create(PostList::create($posts), ItemList::create());
5.         $html .= Footer::create();
6.        
7.         parent::Template($html);
8.     }
9. }

View templates use a number of modules to build up the page; Header, PostList, ItemList and Footer in the above example. These modules make up different parts of a page and can take parts of the model as parameters as is the case here. Combined, the modules produce the desired HTML for the page. It should be mentioned that there is no specific reason that the view must output HTML, it can just as well be XML of some format.

With these additions the show method in the controller now looks something like this:

1. public function show($param){
2.    $posts = MainModel::read();
3.    $template = new MainView($posts);
4. }

The next step only applies if you're constructing an ordinary HTML page. If not, you can just return the code generated by the view. The framework has a utility class called Page which makes it easier to create all the parts which make up a standard HTML page, including meta tags, styles and scripts. You might want to modify the class to suit your needs as it is not prepared for all possible contingencies. The class uses the template created by the view to create the page:

1. public function show($param){
2.    $posts = MainModel::read();
3.    $template = new MainView($posts);
4.    $page = Page::create($template,"Demo Page")
5.       ->addStyle("default.css")
6.       ->setDescription("This is a default page description.")
7.       ->setKeywords("these, are, example, keywords");
8.    echo $page->getHtml();
9. }

This example creates a page with the title "Demo Page" and sets the stylesheet as well as the meta information for description and keywords. Each of the functions on the page returns the page object so you can easily chain the page configuration calls as done above.

This is basically what it takes to create a page, though as I hinted at, it is possible to change the approach for special types of views such as XML feeds or an AJAX API. Some pages might not need a model or even a view and as such the term 'page' applies in a very loose sense. In upcoming posts I'll provide examples of alternative page types.

I've updated the framework code to use the example used in this post and the style for it is now based on one of the free styles from Free CSS Templates, which also supplied the style for this site.