appearance and conventions

I don’t like HTML in PHP. Or, worse yet, PHP in HTML. Now, obviously this is a matter of preference and there are benefits and difficulties that accompany each method.

Adding PHP to HTML is quick and easy. The main problems being that it can then be difficult to find your PHP in the mess of HTML, especially if your HTML isn’t clean — and that the idea of trying to implement a system of any complexity in this manner disgusts me. Maybe not a problem for you, but certainly one that prevents me from using this method as much as possible.

Adding HTML to PHP is the middle ground. It is easy, and good for initial testing as you only have to edit the one file that contains both the PHP and the HTML it outputs. But, again, it is not a method that I would choose for a final product, although it is a method that I would use under the right constraints. The problem with this method is that anyone who wishes to change the way the output is formatted will have to edit the PHP file itself. This is less of a problem if it is you who is editing it than if it is someone who is unfamiliar with the system, but still there is the possibility that even a simple change in formatting can temporarily break everything – typos are more common than a cold. This is also less of a problem if the HTML you use to format your output is nice, and can be styled with an included CSS file.

Preferably, interface and function would be kept entirely separate – or at least as much so as possible. Of course, doing that in a way that is both general and flexible is understandably more difficult. Separating interface and function allows for easy switching of themes and skins (that can be very different, visually) and, at least to me, is more elegant. (By which I mean, it doesn’t make me feel sick)

My next blog should explain the method I used to allow for this in the project I am currently working on.