Smarty

[JerryVL]

I have been considering the benefits of the 'compilation' Smarty performs of templates into PHP code, and have been thinking about using a similar system to optimise handling of extensively configurable functionality in web-sites. Let me illustrate:

A most(all?) CMS systems out there have loads of modules which can be configured for inclusion in the system available to its users. In addition most of these modules have parameters which can be configured as well.

These systems typically store the configuration and whether or not modules are active in one or more database tables. This means that every time a page is loaded for the CMS, the system will access the database to find out which modules need to be included and what their parameters are. Following this, it will INCLUDE! each of the required module PHP scripts dynamically.

After some thinking I realised that I could write a system to 'compile' the included scripts and cache the resulting overall PHP in some directory somewhere, but this is pretty much exactly what Smarty already does.

Now here is my question; does anyone have any experience in subverting the Smarty system in some similar fashion to 'compile' functionality into more efficient PHP than the original fully dynamic PHP? If so, are there any pitfalls / downsides to this approach?

What I was specifically thinking of is having an 'admin' system, which upon changes generates the appropriate root 'include' files, which statically include all the currently active modules with the appropriate parameters explicitly set, then using Smarty to load these loader files as part of the preamble to the actual site templates.

I have investigated some of the Smarty internals to see what it does, but I do not know it intimately enough yet to see if there are any unknown unknowns that'd mess this up. Also, would anyone more knowledgeable in Smarty be able to hazard a guess as to what the actual savings might be using this approach? (i.e. is it worth doing, or not?)

Regards,
Jerry

[boots]

Hi, JerryVL.

I'm interested in this topic. I'm not sure Smarty will produce "optimized code" but it can be handy as a data intermediary and the caching and compiling can be leveraged fairly directly. The key idea for me is to see Smarty as being able to generate output in languages other than HTML.

My approach has been to consider the data flow and state transitions. I divide the usual tasks in a fairly standard-way:

- determine current state (decode input)
- retrieve configuration data for current state (app specific)
- output current state template with current state configuration data

I approach the configuration items you talked about as pure data (preferably in a manner which can be readily serialized). Data maintainers write definition files using Smarty templates which result not in HTML but in a data language of your choice--I use a custom parser for a custom syntax but something like XML would work. The result is fetch()ed and turned into a PHP serialization (perhaps with an output filter). Smarty handles the template compiling and the caching requests (in one scheme my state controller automatically adjusts Smarty's compile_id and cache_id items as required). Application functionality is provided through plugins (as well as custom resources) to the data maintainers. The returned data structure has a payload (the actual data) as well as additional properties that report processing condition so that the state controller can do additional work as required. In general, the payload is passed to a standard Smarty template for output.

You'll note that this means as many as two calls to Smarty (one to process the data and one for the output template) as well as the overhead of the serializer. On the other hand, if you have more template states than data states (likely) you get all the benefits of Smarty's caching for the data retrieval portion of the request, which I believe is precisely what you are after. Separation is heightened: data maintainers have access to outside data (but in a controlled way through plugins/resources) while template designers can only access what is passed to them. This helps enforce what I think is a good policy in terms of allowable content in output templates: no data retrieval, no data generation.

The problem I'm having with this "dynamic definitional" approach is that it requires a lot of structure (ie. definition) from the get-go. You need a lot of framework to tie together a specific application model with a specific template model, IMO. I've only played with the idea so far and have only used it to implement a menu scheme--it works, even though a bit trivially.

Have you gotten any further in your trials?

[JerryVL]

I haven't had a chance to try anything more since yesterday (I'm in Australia, so our perceptions of today/yesterday may vary , but I did have another idea overnight.

Most CMSes use large lookup tables for language translation of site-specific text, with the in-code text being in English and serving as the key in this lookup. This has always seemed a bit inefficient to me, and this struck me as even a better example where templating might help... all source listings could initially be treated as templates, which are populated with the language-specific strings through Smarty, after which they can be re-read from the cache at no further overhead.

Once I get (any of these ideas) in an operational state I'll primarily want to do some performance comparisons to get a feel for the actual savings, because as you pointed out, the framework of the application is going to turn out more convoluted than it could otherwise be... this is naturally only acceptable if there is a sufficient up-side in gained performance for the total solution.

I'll now go re-read your reply again, 'cause I only got the gist of it on a first skim... your writing is a bit densely packed with information.

[JerryVL]

Also in reply to your original post, ... it occured to me that maybe the Smarty engine has a valuable sub-component in its caching mechanism... I'd have to have a look in the source to see how integrated it is with the rest of the code.

To expand on this point:
I have had a look in some output generated by Smarty, and the one down-side I saw from the perspective of using it to transform/instantiate PHP code is that there is quite a bit of extra code involved in maintaining and manipulating the state-space behind the scenes so that the templates work as expected.

This extra code would often be redundant in my scenario because a lot of it could be implemented through static substitutions and expansions of the input source code. In effect, the valuable Smarty asset that I am trying to leverage is the caching mechanism that ensures that I do not have to go through the substitution process on every page invocation.

This is of course a bit of a simplification, but the main point is that it might be worth looking if the caching system can be used independently of the rest of Smarty. (If this makes any sense)

[philjohn]

There is a pear module that does this (pear::cache_lite IIRC), basically you cache output of scripts to disk for a particular length of time (the time to live of the cache). This allows you to generate certain things only every now and then.

Secondly I agree with you on the whole multi-language thing. Why store it in the database? A database lookup is going to be slower than a hash stored in memory read from a php file. Or you could do internationalisation the proper way and use the gettext functionality build into php.