I've extracted two primary questions for me and I'll do my best to respond to them. Keep in mind I'm really just presenting my personal reasoning, and I am not a Smarty guru, so any corrections on claims I've made about Smarty would be welcomed!
Really it's difficult to provide examples on a large enough scale to cover the language. It's really a project in and of itself to set up appropriate documentation. It is something I would like to do, and plan on doing. For now, the various unit tests provide a very lame set of examples of edge cases and regular use of individual tags which you can check out.
"Why use a template language at all?"
There are more situations in which a template language is the wrong choice than there are in which it is the right choice. There are, however, some benefits to running a scripting language over PHP and I will list them:
Primary Reasons:
1) Ability to reflect on what has been parsed. With a PHP "template" you really don't get anything more than you put in to it. This means that if you wanted to keep track of all the links that were displayed you would end up needing to parse everything anyway. Let's say you want to create a CMS solution which detects fields such as "title" "body" "title image" and so on so that you can get that information from someone managing the site and display it appropriately later? This allows you to have the output of such a field be directly tied to the detection of it and really streamlines the process. This primarily helps to plug in an otherwise basic html file with a couple curly braces into an existing framework like a CMS for interpretation and streamlines the production of sites when you're on a schedule.
2) Ability to control the executing environment completely. This means you do not have to worry about user-submitted code in any situation where you might expose the language to them. Mailing list software frequently makes use of mail templates, social sites may offer a range of flexibility for output of the user's page and a template language might be appropriate to expose to power users... These situations may not be appropriate to actually expose PHP to those users.
Secondary Benefits:
3) A true domain specific language which you can tune to display the HTML of your project. You can create a tag to display a user for example {DisplayUser|({$UserSession[User][Id]})(narrow)} (note, similar idea to a view class). Express your intent directly. This is, of course, a contrived example, but even if it's only a thin semantic wrapper, it can be beneficial to write this:
{url|
http://www.someplace.com/({$path})/({$f ... {$value2})}
vs:
echo htmlentities("
http://www.someplace.com/".rawurlencode ... ode($file).
"?value1=".urlencode($value1)."&value2=".urlencode($value2));
4) One more layer of presentation stripped from the actual logic. This is the fourth and least important point as it can be replicated in function by Model View Controller frameworks such as CakePHP and the Zend Framework. This is in contrast with Smarty's "why use" page which basically tries to sell you that this is the most important thing a template language can do.
"Why this over Smarty?"
This is a very good question and one which bears scrutiny. Smarty offers a few key benefits this project lacks, the primary ones being built-in caching and compilation to PHP before execution instead of interpretation directly into output. I have not run benchmarks, but I strongly suspect Smarty will out-perform Muted Template performance-wise. How important this is depends largely on the scope of a project.
That said, I do plan on introducing caching. Compilation to PHP would be a big task, but is something that I believe could be achieved and I was planning on approaching this as a separate project if the language started to gain popularity. Before that I need to set up a proper documentation site as I mentioned earlier.
Now, with that said, the benefits you have with Muted Template over Smarty are primarily in the flexibility of the parsing mechanism. The Smarty parsing system is built around regex which makes certain things kind of clunky and generally means that nesting tags must be supported by each tag developed (as I understand it). It also means that we can more intelligently deal with braces you may encounter within javascript or CSS without having to use something like {literal} every time you want to use a bracket.
Beyond this, the language is slimmer and tighter, but provides more structure (Smarty is heavily attribute based, Muted Template relies more on parameter lists).
This is just a very basic comparison of a foreach loop:
Muted Template:
Code: Select all
{each|$a|($key)($value)|
{$key} = {$value}<br/>
}
Smarty:
Code: Select all
{foreach from=$a key=$key item=$value}
{$key} = {$value}<br/>
{/foreach}
However, if you wanted to notate the key and value with labels, Muted Template ignores everything outside of the () in a parameter list, so you can write notation such as if you prefer:
Code: Select all
{each|$a|key=($key) value=($value)|}
Let's look at setting variables:
Muted Template:
Code: Select all
{set|($variable1)(value1) ($variable2)({math|5 * 2})}
or, more clearly:
{set|($variable1) = (value1), ($variable2) = ({math|5 * 2})}
or, if you like:
{set|
($variable1) = (value1),
($variable2) = ({math|5 * 2})
}
Smarty:
Code: Select all
{assign var='$variable1' value='value1'}
{assign var='$variable2' value=`5 * 2`}
It may seem like a minor point, but smarty is -incredibly- verbose and doesn't really lend itself well to compact and easily scannable code. This is mostly because it tries to disguise itself as a markup language when it just is not. Muted Template is unafraid of looking different than HTML, and it is different enough from PHP that it cannot be confused for either. Some people may think this is a bad thing, but I believe it helps keep the language mentally distinct and yet low-profile which is one of the goals considering it is meant to be embedded in otherwise static markup language and things can get messy if boundaries are not observed.
It is important to note here that Muted Template can actually execute arbitrarily nested commands. We could, for example, execute this:
Code: Select all
{set|($a[0]) = (Hello), ($a[1]) = ( ), ($a[2]) = (World)}
{set|($tagName) = (math)}
{set|($result) = ({if|{{$tagName}|5 * 2} == 10|{each|$a|($value)|{$value}}||Boo!})}
{$result}
The above outputs Hello World
It's incredibly powerful, I'm not advocating executing things like this, but the fact that you can is interesting and means that if you -do- need to you are not stuck. I do not believe Smarty is nearly this flexible with its parsing of nested template tags. So primarily I believe the benefit in Muted Template is in language flexibility, nesting, and the syntax. I should mention that in situations where you need to, you can escape using \ to output control flow characters. The ability to escape any control character in a context-knowledgeable way was built in to the language. I'm not sure how or if smarty allows anything to be escaped due to regex parsing.
A good way to get a sense for what the language reads like is to simply look in the Parse Tags folder where at the top of each tag is a quick example of common use.