[wp-hackers] Separation of Application Logic from

Nathan Lamont dr.forbin at gmail.com
Sun Sep 4 17:40:19 GMT 2005

> And is my question "Are we thinking about making WordPress faster &
> lighter or bloating it??" not justified?
> If you can justify it, then I'd sure be glad to hear the reasoning
> behind it!! :)
> And is my question "Are we thinking about making WordPress faster &
> lighter or bloating it??" not justified?
> If you can justify it, then I'd sure be glad to hear the reasoning
> behind it!! :)

The little example on my site wasn't meant to justify the use of
Smarty, just illustrate what I did.

My justification for using Smarty is just like the justification for
using an object-orient programming language over a strictly procedural
one: an object-oriented language offers a structure (or may impose a
structure) a programmer can (or is forced to) use to encapsulate
different parts of logic from one another. This structure, especially
when it is imposed, is not computationally free, and can be harder to
learn. Yet when properly used, it leads to code that is easier to
maintain, easier to reuse, and easier to expand upon.

Some people would disagree with that assertion, and obviously this is
not the place for the OOP vs. non-OOP debate. My justification for
using Smarty is that it imposes encapsulation, has been developed by
people much smarter than me, and so is a better conceived and executed
method of abstraction than I could invent even if I had the time to do
so. For me personally, and I would imagine in a project with multiple
people working on it, a strictly imposed structure, if it is well
conceived, leads to a better structured program. I believe Smarty was
well conceived and is well executed.

Here is a very simple example of what I mean by encapsulation. In
`wp_admin/edit.php`, we have:

	if ( ('none' != $comment_status) && ($user_level >= 3) ) {
		if ('approved' == wp_get_comment_status($comment->comment_ID)) {
			echo " - <a href=\"post.php?action=unapprovecomment&amp;p=" . 
				$post->ID."&amp;comment=".$comment->comment_ID."\">" .
					__('Unapprove') . "</a> ";
		} else {
			echo " - <a href=\"post.php?action=approvecomment&amp;p=" .
				$post->ID."&amp;comment=".$comment->comment_ID."\">" .
				__('Approve') . "</a> ";

This is the opposite of abstraction -- the user's level is compared to
the hard-coded value of 3, for example, and the output is generated
directly as a result.

While working through my hack, it was easy to see that this hard
comparison was less than ideal, and could change in the future --
deciding whether or not the user had permission to approve comments
certainly didn't belong in the template. The template only knows what
you explicitly tell it -- this is what I mean by an imposed
encapsulation -- so you must make a decision about every piece of
information. So my version has:

	$smarty->assign('can_approve_comments', $user_level >= 3);

in `edit.php` and:

	{if $comment->status != 'none' && $can_approve_comments}
		{if $comment->status=='approved'}
			- <a href="post.php?action=unapprovecomment&amp;
			- <a href="post.php?action=approvecomment&amp;
		{/if}{* / comment status *}
	{/if}{* / can approve comments *}

in the template. This is not about syntax, this is about abstraction.
This is  so the template doesn't need to know how a decision is made.
(Ideally it wouldn't be using string constants, e.g., `approved`,
`none`, to check the comment's status.)

No, Smarty isn't the only way to do this. But just as I wouldn't try
to write a WordPress from scratch when such a beautiful job has been
done with it already, so I wouldn't try to write a templating library
when Smarty let me hit the ground running.

I completely understand the desire to keep WordPress small, light, and
manageable. I've never managed or maintained an open source project,
so I would never pretend to understand how difficult it could be, but
my feeling is that the hard work of writing and maintaining a template
library has been done -- isn't the point of open source to leverage
one another's work? Smarty would add 500K or so to WordPress's size,
but it would be 500K of well written, well maintained, and field
tested code.

More information about the wp-hackers mailing list