Smarty

[Ants Aasma]

I had an idea for optimizing the performance of compiled templates.

When modifiers/functions/includes are static, their output might as well be compiled into the template.

A naivé implementation would be to use special compiler directives in plugins to imply, that for a given set of parameters the function/modifier always returns the same value. Even simpler with includes, where the include syntax could be extended with a static parameter or a new {inline file=""} syntax could be introduced that could be parsed with a prefilter. Then the compiler can check if the parameters are static (ie. config vars, explicit strings etc.) and when they are calculate the result and inline as HTML. Would add a need for additional checks for recompilation though, if the inlined template or function has changed, the template will need to be recompiled. Although constructs such as {include file="header.tpl" section="Files"} or {#SiteName#|capitalize} are pretty common, they are fast enough to probably not give any appreciable amount of speedup. Probably useful if one wants to do things such as {inline file="checkedInput.tpl" name="forumtext" maxlen=68} effectively a LOT of times on a page.

Where it could make a remarkable difference is in compiling infrequently changing things such as {HTMLimage file="myImage.jpg"} . In such cases a neat thing would be for potentially inlineable functions (another compiler directive in function header/registration?) would emit a resource tag which would be embedded into template, so that a check could be added into compiled output, weather to invoke recompilation. Something such as

[boots]

Ahh, someone after my own heart! I think you may find the discussion that messju started here interesting.

I started this discussion on the related matter of getting $this into modifier functions. Handy for my inline assign If you follow that thread, you'll see I also mention a modifier library context function and a patch to allow optional whitespace in the modifier syntax.

Perhaps you will have some more ideas after you get some sleep!!

[Ants Aasma]

Another idea to make templates more readable to the design people

Template code:
{$name|if:$showName|else:"name Hidden"}
or alternate syntax
{$name|if:$showName:"name Hidden"}
without the else part
{$name|if:$showName}

The if modifier is
function smarty_modifier_if($true, $predicate, $false = '')
{
return $predicate ? $true : $false;
}
And else modifier is an alias for default

Or maybe in another order, not sure about the name
{$item.Selected|pick:"selected":"not selected"}

function smarty_modifier_pick($predicate, $true, $false = '')
{
return $predicate ? $true : $false;
}

Or new syntax for vars
{$predicate ? $true : $false}

Those could be handily optimised compiletime or with a prefilter into regular if's, but they do make the template quite a bit more readable.

And that brings to mind that if's could also be unraveled, if they are static.
ie.
{if #showDescription#}
<TD>{$Description}</TD>
{/if}
would check from config file if showDescription is true and if it is handling it just like
<TD> {$Description}</TD>
else it would just omit that section from the compiled code.

On a different note. I checked the Smarty source a little both current distribution and CVS. AFAICS the parsing of config file is deffered until config_load which means that configvar values are unknown at compile time. After thinking about possible config_load uses, it makes perfect sense. It is pretty difficult to check what the values would be runtime.
Some things can be worked around easily, others are a lot harder.
For example if config_load is called from the application the template can be comiled into different files for each copy, assuming no config_loads in template.
For config_loads in template it gets tricky. We would need to evaluate each config_load while compiling and keep track of the values. Not that complicated at first sight, but what makes it tricky is that config_loads can be called from included templates and modify the scope of the current template. Solution would be to compile each include too and see what vars are imported to the current scope. Would need some rearrangements, but definately doable. But this assumes that config_load and include parameters are known at compiletime, which isn't always true. Consider {config_load file=$myConf}. It is possible to some extent to note at compiletime which assigned variables influence the config_load and compile a version for each value encountered but if one takes into account that {assign} and other template functions can modify the value of the variable, its just impossible to do that kind of optimisations. Atleast without limiting config_load and include functionality.

I still like the idea though. Espescially with caching the results of static functions. Must think of integrating some sort of caching engine into Smarty. With that, this would make a lot more sense. A lot more than just changing bgcolor="<?php echo $this->_config[0]['vars']['tableBackground']; ?>"[/y] into [i]bgcolor="#CCCCCC". It would mean plugins that compile a WYSIWYG editor according to configfile or do whatever that takes a lot of time.
I have a dream of separating application logic and UI completely. Its pretty vague yet, need to do some more thinking but the general idea is that all the programmer does is creating a library with all the application logic. That application logic doesn't know anything about anything about where it is used. It is some what doable with current Smarty, but query string management is a real burden on the programmer. For example if the designer thinks that some news headlines on some random page would be pretty nifty, the programmer needs to know nothing about it. The designer just uses the {News} template function for that.

Anyway, I would love to hear some comments from Smarty developers about what they think of an optimizing compiler.

[boots]

- I tried the if modifier in the past--not 100% sold on it yet, though.
- You can use plugin compiler functions to build things like {compile_if}.
- I'm not sure where you were going with config_load ?? Are you aware that Smarty's config_load causes config files to be compiled? Take a look in your templates_c dir Personally, I'm more interested in a generalized data loader.
- Smarty also has a caching engine and FWIK, allows you to swap in your own, as well.