[geeklog-devel] caching template library

[Joe Mucchiello]

At 09:00 AM 11/1/2007, Tony Bibbs wrote:
> I'd only point out the obvious, by delaying again and again moving to
> a more supported template system we now eat the responsibility of
> maintaining that code.  It may be that Joe's improvements to PHPLib
> aren't that much work to maintain (which would be good), but I still
> feel at some point it will be an inevitable move to something like
> Smarty, Flexy, et. al.

I'd like to think it isn't too complicated but some of the interactions
with the set_block function are real head-scratchers at times. 

At its heart, the changes are conceptually simple. Take the current
template file and output a php file that substitutes the variables
directly. Thus "{variable}" becomes "<?php echo
$this->val_echo('variable'); ?>" where the val_echo function takes care
of the if (array_key_exists(...)) stuff. There is also a block_echo
function for dealing with blocks.

When you call parse(), the code just calls "include $cachefile". The
speed up results from PHP's own compilation and caching of PHP files.
Arguably this means you can put PHP into any template file. I don't
think this is such a sin though since currently header.thtml is always
parsed through eval() anyway.

Additionally, I think functions like COM_createLink could be moved into
template files since processing the cached file should not be a big
speed hit. (Especially if the template object instance is cached in a
static inside COM_createLink.)

> The common argument is "what about all the themes out there that'd
> have to change?".  While it is a valid concern, we only support one
> theme now (a good decision I'd add) and I feel the rich features of
> some of the better supported template systems will encourage theme
> developers to convert or build new themes.

Well, you can't get more powerful than templates that run as PHP. :-) 

Also, I've added a few additional features. For example, {variable:u}
will call urlencode on the variable before outputting it. {variable:s}
will call htmlspecialchars. This is similar to Flexy/Smarty with one
important difference for Geeklog: in Flexy, calling htmlspecialchars is
the default and you can only prevent its call with :h. Geeklog outputs
HTML deep in its core and converting an existing template to be Flexy
compatible would mean adding in lots of :h's. With my modification to
PHPlib, the assumption is reversed and that means little to no core
modifications.

More useful is that {$LANG01[12]} will output the content of the listed
language global. If you really want to separate content from layout,
every set_var('lang_save', $LANG_ADMIN['save']) could be removed from
the system and moved into the template files. (When I get the chance
I'm going to modify a set of templates and php code to make this change
to see if that speeds stuff up even more.)

> Sure, compilation is nice...but what about magically
> escaping output to help combat nastiness like XSS? Using method calls
> in templates?  Native translation support?  Simple control
structures?

Done and done. Simple control structures would be easy to add but I
didn't want anyone saying I'd done too much to the lib. The cost for
these changes is more and more regexs when the template is cached. Once
cached these things have zero additional cost. But if someone wanted
for and if in there, I can add them in a few days (after I return from
vacation). I know. Why roll our own when there are libraries like
Smarty and Flexy? Well, not having to rewrite every "new Template" call
in Geeklog has far greater value than you attach to it, I think.

There are other little bonuses in the library as well. Set_root() now
takes an array so, for example, a plugin could ship its templates in
plugins/$plugin/templates but search for templates in
Array($_CONF['path_layout'].$plugin,
$_CONF['path']."plugins/$plugin/templates") and theme writers can
override just the files they want to and leave the default files as is
without having to copy those fies around. As a plugin author, this
change, I think, is even more useful than the caching. Sites with many
themes will find this most helpful when installing some plugins.

> Generally I agree in doing small bits of work to incrementally
> improve a product but there are times when that just won't do and
> I'd simply ask if that time isn't now?

Tony, my guess is that anyone who wanted to do that much recoding would
be doing GL2 work with you. PHPlib+caching provides many of the
benefits of Smarty/Flexy without a lot of code changes and leverages
all of the existing GL1 code. That's hard to ignore.

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com