[development] theme_foo() functions vs tpl.php templates (was Move all core modules into their own directories)

Thu May 4 13:49:40 UTC 2006

On 04 May 2006, at 2:45 PM, Jeremy Epstein wrote:
> I too am a big fan of PHPTemplate, and I don't even consider using a
> different engine when I design themes nowadays. But I think that the
> flexible theme engine system is a huge strength in Drupal, and that
> removing it would be a Very Bad Idea (tm). The plain PHP theming
> system is probably not worth using, for most people, but I think that
> it should remain to please the puritans among us (and besides, its
> overhead is minimal compared to the engines).

There are often times when PHPTemplate is a bad idea. When
security is an issue and you need to give people the ability to write
non-executable templates, for instance.

I still believe that PHPTal is in fact far superior to straight PHP,
and I hope to one day finally move to php5 and help make the
phptal engine all it can be (believe me when I say that it has a very
very very good chance of blowing the themeing capabilities of any
other cms out of the water, if done right).

> The best-maintained theme engine in contrib is the Smarty engine, and
> ensuring continued support for this engine is IMO very important, as
> Smarty and Smarty-like template systems have become the preferred
> format for designers. I worked on a project last year where the client
> insisted on using Smarty templating, because their graphic / web
> designer was very familiar with it. I'm sure there are many stories
> like this one. Designers don't want to learn PHP in order to create
> templates: removing support for everything except PHPTemplate is
> guaranteed to turn off designers from using Drupal.
The smarty engine is based on PHPTemplate.

So much so that if phptemplate were moved into core properly (and not  
just included with)
it would cut smarty down to a couple of dozen lines of code and  
collection of template files.

Same with PHPTal (currently).

>
> As for the issue of theme_foo() functions in core getting replaced
> with foo.tpl.php templates: I think that this is a good idea, but it
> needs to be done very carefully.
>
> First, it will mean that PHPTemplate becomes an integral part of the
> theme system, rather than just an add-on engine. So the core theme
> system will have to be re-designed somewhat, to accommodate both
> PHPTemplate and theme_foo() functions being supported at all times.

Not really. This was how it was initially designed to work.
For now, i think the best mechanism would be what jonbob suggested :

1. theme functions call the theme engine (_engine_callback('name',  
array('var1' => 1, 'var2' => 2));
2. the engine_callback hands that off to the first available thing it  
can.

> Which brings me to my second point: no, I don't think that support for
> theme_foo() functions should be dropped! Really small themeable
> functions are not worth writing a template for - there should be a mix
> between tpl.php templates in core (to replace the longer of the
> themeable functions), and the current functions that we have already.
> I know that many people want consistency in this, but personally, I
> would rather sacrifice consistency, than have 50 one-line tpl.php
> files in core. And, we should still be supporting plain PHP themes at
> all times (not to mention support for engine_foo() functions).
I'm on the fence about this. While i am worried about the overridabilty
of stuff like theme_table, i feel _very_ strongly about separating code
and markup.

And this won't be an invasive change.  Old style themes will still work,
although I would prefer themename_ becomes template_ so that
_all_ themes are copyable. not just templates. ALL themes.

> Third, the defining of templates and their variables in PHPTemplate
> needs to improve before any of this can happen. Having to define a
> function in your template.php file for every template is already a
> PITA, and it's not what we should be doing when we start putting
> templates in core. When you call theme('foo'), PHPTemplate should be
> able to just go off and find foo.tpl.php without needing it defined in
> a function (or in the engine itself, or wherever). Same for variables
> - they already get passed in as parameters to theme('foo', ...), so
> they should automatically be available in the template, without
> assigning them all manually in an intermediary function.
Yup. mentioned that.
I have some ideas for getting rid of requiring the variable  
definition part.

1: pretty invasive, but probably correct way :
    When using theme functions, call them with an associative array  
as the second parameter.
    Could probably be scripted. ie: instead of theme('node_list',  
$nodes) it would be theme('node_list', array('nodes' => $nodes));

    I'm willing to let this slide, but part of this is why FAPI is so  
easy to theme. FAPI 2.0 is going to build on this, and by 5.0 we  
might likely
    have this, although it will be completely invisible to  
development (ie: the render() function that can render parts of the  
tree).

    Don't be scared of this though, FAPI 2.0 is going to be a lot  
simpler than what we have currently, particularly because of it's  
unification.
    Look how much simpler the re-implementation of the table themeing  
is :

2: the gets us where we want to be , but with a lot of extra possibly  
unnecesary code method :
    replace the theme_ functions with the template variable stubs. I  
think this is the quickest way to get us where we want.
    I think this is the best solution for now. And can be very easily  
scripted too.

3: glorious meta information
   once modules have meta-info, just register the parameters like

   [templates]
   node.tpl.php = node, frontpage, someotherthing

   But that doesn't get us fun things like the alternate template  
parameter.

>
> The stuff in my third point quite obviously needs to happen, IMO,
> before tpl.php files in core can happen. So I'm sorry if I'm just
> re-stating things that Adrian et al have already got planned - I
> haven't seen these points discussed anywhere yet.

I am going to write all this stuff up for the theme development  
special interest group
on groups.drupal.org
and i will cross post it here too .

--
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com