|Object-Oriented HTML Generation In PHP
|Written by Alex Armstrong
|Friday, 27 November 2020
Page 1 of 3
PHP is a programming language specifically designed to generate HTML pages, but one of the topics that is rarely discussed is exactly how to do this. In this article the idea that HTML generation should be object-oriented is proposed and explored.
So how do you generate HTML?
The fundamental problem of using PHP is how best to actually generate HTML.
It is important to know that I'm not offering any hard solutions to the problem just raising some considerations and possible ways of doing the job.
Before going on to consider some solutions let's look at the nature of the problem in more detail from the very basics.
You might not think of it as a problem but mixing code and markup is never a good idea and it certainly isn't pretty.
Why should you worry about how pretty code is?
Because pretty code is easy to read, easy to understand, easy to modify and easy to debug.
The problem is that a PHP page can contain a mixture of PHP and HTML. The PHP has to be within <?php ?> tags and the HTML can be anywhere it pleases. In a sense the PHP code is a stowaway in an HTML page.
So for example, you can write:
which first outputs the text "hello world 1" from PHP, then lapses into HTML to create a button and then goes back to PHP to generate the second piece of text.
Notice that the idea here is that anything that the PHP code generates is inserted into the final HTML page.
That is the basic mechanism of generating HTML in PHP is to write it to the output stream.
This approach of seeming to mix the HTML and code is often referred to as inline code and in this simple example it isn't too bad, but take a look at a page where PHP is used to generate some complicated web pages layouts and the result is usually very difficult to follow with lots of PHP fragments scattered through lots of HTML fragments.
PHP being a server side language could adopt a "code behind" approach like ASP .NET programmers tend to use but the structure of the language and its relationship to the HTML means that this doesn't work very well. In code behind the HTML and the code are separated into different files and the code manipulates the HTML.
The basic idea is to treat the markup as a language that creates objects which the code can work with.
The best examples of this idea are in Flash, now obsolete, and .NET where MXML and XAML are used as object instantiation and initialization languages.
In short, the markup creates and initializes objects which the code then manipulates. HTML, however, doesn't actually create anything until it reaches the client and server side code has finished running by the time it creates any programmable objects.
What this means is that client side code can consider HTML to be an object-instantiation language, but this is difficult for PHP.
This is an important observation and we will return to it and its implications later.
The obvious alternative is to try to separate the code from the HTML by always making the code generate the HTML i.e. don't actually have any HTML code.
This works up to a point. For example the previous mixed HTML and PHP program could be written as:
In other words, instead of having to drop in and out of PHP to write some HTML, we simply use strings for the HTML tags and echo them to the output.
This may seem like a small and almost pointless change but it does have some advantages. In particular, it stops the mixing of HTML and PHP control structures.
For example suppose we wanted five buttons in the previous example. Then this could be achieved using:
If it has never occurred to you to write this sort of code then try to forget it once you have followed what is going on.
To any reasonable programmer this sort of expression is horrible.
The program starts off in PHP and creates the start of a for loop. The PHP ends and some HTML occurs, followed by some more PHP complete with the end of the for loop. The result is that the for loop repeats 5 times and repeats the HTML as if it was written five times.
This is horrible because the interaction of PHP and HTML is quite unnatural. Used in this way PHP looks more like a scripting language for a word processor or text editor.
Notice that the same sort of behavior works for all of the other PHP control statements and the result is just as objectionable.
Using the generate all HTML approach the same loop can be written more reasonably as:
Now we have a standard for loop which simply repeats an echo command five times and all in PHP with no sign of any odd interactions between PHP and HTML.
The problem with generating all of the HTML that a program needs in this way is that as the amount of HTML increases the need to quote it or to build strings up that contain it obscures the meaning and layout of the PHP program almost as much as mixing PHP and HTML.
Also notice that you can't do what the program listing above suggests - i.e. you can't format the contents of the string to make it more readable!
This is a better, but not perfect, approach - and sometimes it can seem like a lot of additional work for little gain. The temptation to drop out of PHP and simply write the HTML is often too much to resist.You can make use of Heredoc syntax to simplify the creation of multi-line strings complete with the values of variables already slotted in.
In this case the variable $name is expanded to its current value i.e. world.
However, as before, if there is a lot of HTML to encode as Heredoc then the result is almost as difficult to read - especially so because you cannot use indenting to mark out the Heredoc block - the EOT; has to be at the start of the final line.
If you carry on down the road that this example suggests you end up inventing a template engine. There are lots of PHP template engines and they are worth using and it is a better approach than an unstructured mixing of HTML and PHP.
But is there a better way still?
|Last Updated ( Friday, 27 November 2020 )