17 August 2006
Using HTML as a Template
There are roughly three ways I can think of offhand to do templating in PHP.
- HTML Tags with PHP to populate values
- PHP Functions to generate tags including values
- Special markup to do one or more of the above
There are relatively concrete examples of each. Any new programer, and even some experienced programmers use method 1. Indications of this style are many lines in output which look like <h1><?php echo $pagetitle; ?></h1>. It has advantages in that its easy to get stated in and to debug. The learning curve is very low. Disadvantages are less-than-ideal rendering in WYSIWYG editors, and the template is tied very closely to the code which populates it.
Method 2 is similar to method 1, only it also undertakes writing the surrounding HTML. This is perhaps most useful when populating forms. You’re probably dealing with this code when you see a line reading like <?php echo drawTextbox ('name', $name, 18, true, true); ?>. There are advantages, such as no time spent diagnosing bad HTML and the inherent gain resulting from abstracting goals from implementation, but the negatives are much more obvious. For one, a designer has no idea what that block of code does when working in DreamWeaver. It’s just a little yellow square. In Method 1, they could at least identify the H1 tag. With labels by the sides, designers can figure it out but it does take more thought. For two, and perhaps most importantly, the learning curve is aweful. Few programmers care to memorize these functions with more than three parameters, and to offer the flexibility of HTML in a function, most any tag will require more parameters than that.
There are object-oriented alternatives from this which at least relax the number of parameters involved, but they still have a learning curve and really only move code from output to logic.
Method 3 is currently the most interesting. It’s names are perhaps most familiar to web developers: .net, Prado, Smarty. In any of these systems, there are whole-new languages to handle output. Though .net is .net and Prado is PHP, we shall consider them one for this topic. .Net uses XML tags to specify placeholders for rendered tags (not to be confused with the PlaceHolder control). At runtime, as execution flows through the logic layer, controls are built and then substituted over the specially crafted XML tags before being passed to site users. Behind the scenes, they are managed much like the object-oriented variety of Method 2, but for designers, <aspx: …>…</aspx:…> tags render as the correct element (at least within Visual Studio). It is therefore beneficial to designers, at least, because they will actually see the real page content. The learning curve is still there for developers, however, the experience is much more akin to desktop application design and should therefore prove psychologically easier than otherwise.
Smarty, too, is similar, however, it is more functional than object-oriented. It has special tags marked by curly braces, so they will show up in-line with page text rather than as a DreamWeaver hidden block. However, since each {statement} invokes internal functions, there is more than simple textual replacement happening. Plus, like Methods 1 and 2, program control is at least offered to designers.
I suppose that I am biased towards Method 3’s XML solution. .Net is what I modeled Fortitude Forms on. However, over the last few days, I’ve been thinking about a subtly different solution than XML tags. To begin with, consider writing the template in pure HTML. There are no fort: tags, no aspx: tags, not even a tcom: tag. Instead, there is a <input type="text" name="tbxName" value="" /> tag. When the view is requested, a parser would find each named element that had a counterpart in code, and replace the HTML statement with a rendering function, and then cache the compiled
view for reusability. I imagine it would be too expensive to re-preform this parse each time. Special solutions would need to exist for unique un-named tags like <title>. Perhaps title would just be a special property in a Form object. This is obviously not exceptionally different from Method 3 as exists today, but there are two subtle differences: 1-time parsing is more expensive, but all designers see real, actual, identical looking forms to which that will actually be rendered.
I plan to attempt implementing this. I can’t think of any reason this won’t work for properly formed code. The only reason I could imagine .net does not do this is that it would not be XML-strict (because of invalid markup) but this scheme would replace valid markup with other valid markup. So perhaps there’s another issue which I haven’t considered. But if it works, it should be relatively simple to change Fortitude Forms to accepting real HTML. Setting default properties like .net allows would not be so easy but it may come in time as well.