Programmatic Themes

Written: December 12th 2009

For some time now I've been thinking about programmatic themes. That is, themes that are produced entirely in PHP and as a result can be modified entirely by code.

The concept of using objects within code which are directly representative of HTML elements is not a new one, ASP.Net uses this extensively as does Habari for form handling; however, I have yet to see a full theme handling framework produced for WordPress and the idea intrigues me a lot.

Before I go on to consider the advantages and disadvantages of this let me explain a little bit about what I mean.

WordPress themes are really just normal PHP files. Everything WordPress loads in the background is aimed at preparing the data that will be needed when the webpages that make up the theme are loaded. Once this point is reached WordPress chooses which file should be used and it runs with very little intervention, as if it had been called directly.

Some other systems use a more involved process whereby the HTML and some special codes are included within template files. The content system loads this template into a variable and replaces the special codes with content before echoing to the browser. These can be quite complex with markup for insertion, formatting and even repeating regions. Despite this complexity and control these template files are still essentially hand crafted html which is off limits to the code.

What I am interested in is a process without any template files at all. Instead of template files the theme contains a library of PHP objects that represent HTML structures. For example, you might have a menu object into which you add details of the items you want to include. When called the PHP object will output a div tag that contains an unordered list which in turn contains all of the menu items you created within your PHP script.

The concept might be difficult to imagine so let me provide a slightly more involved example using some code.

In WordPress, the functions.php file contains:

1. //create the page object
2. //this handles all the doctype, header, etc.
3. $page = new page();
4. $page->title = the_title();
6. //create a header object
7. $header = new htmlcontainer();
8. $header->width = '100%';
9. $header->height = '200px';
11. //create the content for the main body
12. //use a container object which is a DIV or series of DIVs
13. $contentContainer = new container();
14. $contentContainer->width = '100%';
16. //we went this container to have 2 columns, main and sidebar
17. $contentContainer->columns = 2;
18. $contentContainer->columns[1]->width = '70%';
19. $contentContainer->columns[2]->width = '30%';
21. //we want the first column to contain the post content only
22. //so create a generic container for the content
23. $content = new genericHTML();
24. $content->content = the_content();
26. //add the generic content object into the first column
27. $contentContainer->columns[1]->add( $content );
29. //add the content into the page
30. $page->add( $header );
31. $page->add( $content );

There is only one other template file, the index.php file. This file contains one line:

1. $page->display();

This triggers every item that has been added to the page to output its HTML in order. This creates the page.

So Why is this an interesting concept?

There are a few reasons why this concept interests me. Firstly it puts almost every aspect of the layout into the control of the coders, so you can not only create the layout with code, but easily modify it as well.

Taking the above example, converting this from a two column layout to a three column layout is a matter of modifying a couple of lines of code, or using a plugin to alter it before it is output. Similarly, if you need an extra class, or an extra DIV inserted somewhere you can modify the output of the object so that it is produced.

This concept also makes it possible to create a user interface to modify most parts of the layout instead of selecting from one of several pre-designed layouts. While it is true that a small selection of layouts is generally suitable for most users greater control is an attractive concept.

Finally, the object library can be extended to include objects that do not directly mirror HTML structures, for example, an object that outputs microformat based elements or mapping.

It isn't all good, of course.

Firstly, the additional control comes only where there is additional development to provide interfaces for it so by default this leaves, potentially, quite complex code which new users may find difficult to get a handle on.

Secondly, plugin authors are unlikely to specialise on themes that use this concept when everything else is produced in the usual style. This style is also likely to put much of the layout CSS inline, or at the top of the page, which might make it difficult for plugins that aren't written for this style to override it.

Third, all this object processing creates significant overheards. These can be managed with appropriate use of caching but this will never be as efficient as simply including a text file, which is effectively what normal templates do.

This is entirely theoretical, the amount of work involved in putting something like toghether is significant and not something I would do on a whim, but I am interested to know what people think of the idea, or if they know of somewhere that this is already a reality.

---

Feedback

Add new comment

Name

Email

Web Address

Is ice "hot" or "cold" (usually)

Subscribe to coments by email?

Say your piece