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

[Jeremy Epstein]

On 5/4/06, Robert Douglass <r.douglass at onlinehome.de> wrote:
> Neil Drumm wrote:
> > I would actually be okay with removing the whole engine system and
> > simply doing PHPTemplate only. Sure theme engines are a nice feature,
> > but how many are maintained and what % of themes are PHPTemplate?
>
> I don't use anything but PHPTemplate, but I think that we want to keep
> the engine system. Why don't we just leave the theme_ function inclusion
> mechanism to the engine? PHPTemplate will require separate files, and
> other engines can do what they please.

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).

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.

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.

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).

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.

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.

Cheers,

Jeremy Epstein
GreenAsh Services
www.greenash.net.au