[geeklog-devel] [geeklog-cvs] Geeklog-1.x

[Joe Mucchiello]

At 03:50 PM 11/25/2007, Dirk Haun wrote:
>Mark R. Evans wrote:
>
> >The final area where Geeklog needs improvement is the template engine.
>
>It's perfectly possible that I'm missing something but what exactly is
>the problem with our template engine? It may be slow but so what - it
>has been slow ever since Geeklog existed in its current form. For me, a
>faster / better / whatever template engine is a "nice to have" feature
>that ranks pretty low on my list. I really don't get all the emotion
>that seems to be involved here.


That's odd that you consider it "nice to have" when in February you 
were saying:

At 06:30 PM 2/10/2007, Dirk Haun wrote:
>Vincent Furia wrote:
>
> >Our
> >template library is extremely inefficient in memory and processing.
> >100s of extra calls to the template library will kill Geeklog (already
> >slow) performance.
>
>Since earlier attempts to replace it with something else have all
>failed: Has someone considered ways to speed it up? Since we're
>apparently stuck with an unsupported template library anyway, we could
>as well fork it.
>
>Hmm, maybe that could be a task for a bounty ...
>
>bye, Dirk


A task you once thought bounty worthy is now "nice to have"? I don't get it.

I can't speak for Mark but being passionate about getting this code 
in would have something to with having a working prototype on April 
28 (it's in the mailing list archive). Since then the extra features 
to the library improve just about all aspects of writing for Geeklog. 
If I never have to code a $T->set_var('lang_foo', $LANG_XYZ['foo']) 
again, I'll jump for joy.


Aside from the speed up, it has the following additional extra features:

Multiple Root directories -- Now plugins can put all their templates 
in the plugin's directory but serve templates from a theme's 
directory if they exist. Think about the forum install, you have to 
move the template files into the theme because Blaine made the 
decision that the forum should be themeable. With this library, it is 
not necessary for Blaine to dictate where the files are, he can look 
in multiple places. He could leave the files in the 
path_to_geeklog/plugins/forum/templates directory and pass 
Array($_CONF['path_layout'].'forum', 
$_CONF['path'].'plugins/forum/templates') to the new Template() call. 
Then any theme that creates forum templates will retheme the forums 
and any theme without a forum directory will use the forum's default 
theme in its internal directory without having to copy the files 
over. Adding themes to any install with the forum plugin is a pain in 
the back because you have to remember to move the template files. If 
other plugins worked the same way, that would become very tedious.

$LANG support -- {$LANG_ADMIN['save']} in a template will spit out 
the language-dependent text. Absolute separation of content from code 
is possible with this function because now you don't need a code 
change in order to add a line of text to the output. For safety sake, 
only variables that start with LANG_ work. Imagine version 1.5.1 of 
Geeklog where there are no $T->set_var('lang....', $LANG....); calls. 
Less code, less requests for text added to templates.

htmlspecialchars and urlencode support -- Does the coder always know 
when he needs to make those calls? Actually, most 'lang_...' vars 
should probably have it but they don't. Now the theme author can add 
those calls to a variable by adding :h or :u onto the variablename: 
{site_url:u}

The cache is PHP -- This means templates can contain PHP code. I 
don't see how this is such a horror considering header.thtml is 
already evaluated in COM_siteHeader(). This just expands that ability 
out to all templates.

Simple if support -- This was brought up in gekklog-devel a couple 
months ago and I had it working in 2 hours. It's not a full if (any 
condition) thing but what it does it does well.

Default vars -- This was an old idea that I added in 5 minutes. Many 
templates need {site_url} and {site_admin_url}. Why not just include 
them in all templates? Now you can. If you add ('xhtml' => XHTML) to 
the default array, you don't need to hunt through the code adding it 
all over the place. This can be made compatible with the old library 
in 5 minutes, too.


All of these extra features though are dead on the vine if the 
library isn't in 1.5. Because based on current trends, 1.5.1 is a 
year away. I want to see themes that take advantage of its added 
features. I can't get excited about a themes that won't exist for a year.


----
Joe Mucchiello
Throwing Dice Games
http://www.throwingdice.com