On 5/4/06, Robert Douglass <r.douglass@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