[development] theme_foo() functions vs tpl.php templates (was
Move all core modules into their own directories)
adrian at bryght.com
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
> 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 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
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
have this, although it will be completely invisible to
development (ie: the render() function that can render parts of the
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
Look how much simpler the re-implementation of the table themeing
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
3: glorious meta information
once modules have meta-info, just register the parameters like
node.tpl.php = node, frontpage, someotherthing
But that doesn't get us fun things like the alternate template
> 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
and i will cross post it here too .
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com
More information about the development