When exploring the differences between the dynamic version of Movable Type and WordPress, it’s easy to get caught up in the one using a template engine and tags and the other using function calls. Those who support tags will say, and rightfully, that actual PHP code in a template can be intimidating to non-techs; but those who support function calls say, and rightfully, that template engines add an extra layer of processing to the application.
A template engine parses the template and generates an intermediate page that replaces tags with actual function calls. The reasoning behind doing this is to separate the presentation from the processing, in this case separate the PHP processing from the (X)HTML. Movable Type uses one of the more well known engines, the Smarty template engine, to handle the tag parsing in its new dynamic architecture.
However, a criticism of Smarty is that it doesn’t separate the processing enough, and can add it’s own level of complexity, as demonstrated in this small example from the Smarty site:
<html>
<head>
<title>User Info</title>
</head>
<body>
User Information:
Name: {$name|capitalize}<br>
Addr: {$address|escape}<br>
Date: {$smarty.now|date_format:”%Y-%m-%d”}<br>
</body>
</html>
But then, all template tag systems have some level of complexity if they’re going to be any use. At least for experienced MT users, they don’t have to learn another set of tags: Six Apart’s developers have extended the Smarty class to ‘translate’ so to speak, between MT’s tags, and Smarty’s. All combined, when you put something like this in a MT template such as Main Index:
<MTEntries lastn=”10″>
<div class=”sidecomments”><a href=”<$MTEntryPermalink$>”><$MTEntryTitle$></a></div>
</MTEntries>
After transformational magic, you get:
<?php $this->_tag_stack[] = array(’MTEntries’, array(’lastn’ => ‘10′)); smarty_block_MTEntries($this->_tag_stack[count($this->_tag_stack)-1][1], null, $this, $_block_repeat=true);while ($_block_repeat) { ob_start(); ?>
<div class=”sidecomments”><a href=”<?php echo smarty_function_MTEntryPermalink(array(), $this);?>
“><?php echo smarty_function_MTEntryTitle(array(), $this);?>
</a></div>
<?php $this->_block_content = ob_get_contents(); ob_end_clean(); echo smarty_block_MTEntries($this->_tag_stack[count($this->_tag_stack)-1][1], $this->_block_content, $this, $_block_repeat=false); } array_pop($this->_tag_stack); ?>
Looks like templates engines make the code a whole lot simpler. But then, look at what you use with WordPress to get the same result:
<?php get_archives(’postbypost’, 10,’other’, ‘<div class=”sidecomments”>’, ‘</div>’, 0) ?>
One of the challenges with a template engine is that you have to account for variations in what people want. This usually means having to build template starting and ending blocks, modifiers, and so on so you can get somewhat complex template tag use. However, with straight function use, you just pass all of this user defined options in as parameters.
As you can see, straight function calls can be simple, and template tags can be simple: it’s how each are integrated into the page that makes the difference. What I think is more important isn’t which approach is used, but how clean the end result is, and how extensible is the underlying architecture. And in these, both Movable Type and WordPress excel, especially with some of the new design considerations with WordPress 1.3. and the intermediate step taken to handle template tag differences between MT and Smarty in the new MT 3.1.
(Weird naming synchronocity, eh?)
(I’ll cover other ‘clean’ tools when I get into porting the Movable Type weblogs.)
As for extensibility, both Movable Type and WordPress are known for their plugin environments, though there has been some criticism of MT’s new PHP plugin environment–existing Perl plugins don’t work with it. However, with Six Apart’s use of the ezSQL database library in addition to Smarty, WordPress plugin authors may now have a new venue for their efforts.
For instance, I have a plugin in WordPress that provides the recent trackbacks, pingbacks, and comments, in one list in my sidebar. I also provide the URL for those who comment, which is why I don’t use the packaged comment functions.
WordPress uses ezSQL for database access, a simplified database API. So does MT for its PHP plugins. Because of the similarity, I could take much of my existing WP plugin and just port it over to MT. The code for the plugin I ported to MT can be downloaded here.
Key code differences, aside from the database structures that set the MT plugin apart from the one in WordPress is the function name, how the database connection is accessed, and the generated text output. Smarty requires that all objects have file names that reflect their nature, such as ‘function.’ for functions, and ‘modifier.’ for modifiers, and so on. The next part of the name is the actual tag element name that’s used in the template, using MT naming conventions, starting with “MT_”. The tag in this case is MTCustomComments. Since the plugin is a function, the file is called “function.MTCustomComments.php”, and the function is named smarty_function_MTCustomComments, the ’smarty’ also being a requirement for the function name within the template system.
Two parameters are passed, ‘$args’ representing any arguments passed to the function, and a reference to the Smarty context, ‘&$ctx’. Looking in the code, you can see how the database connection, db, is accessed through the Movable Type object (that buffer between Smarty and MT), that’s part of the Smarty Context:
$lines = $ctx->mt->db->get_results($sql);
One other difference is that rather than print out the result directly in the function, as I do in WP, I return a string, which is then output automatically within the template. I could do the same with the WP plugin if I was seeking to minimize differences between the environments.
To install the MT plugin, I created a sub-directory called ‘plugin’ in the PHP directory, loaded the new function file into it, and it’s ready to use. In the Main Index page, I then invoke the plugin as follows:
<$MTCustomComments$>
Any PHP function, Smarty Plugin, and even WordPress plugin could be adapted quite easily to the new Six Apart dynamic environment. And this also means that a Six Apart plugin could be easily adapted for use in WordPress. In fact, it wouldn’t take much to create tool-specific wrappers to wrap around functions so they can operate in both environments.
Not just MT and WordPress: let’s not forget other PHP systems with plugin environments, too.
The possibilities are intriguing.
