theme_foo() functions vs tpl.php templates (was Move all core modules into their own directories)
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
On May 4, 2006, at 8:45 AM, Jeremy Epstein wrote:
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.
The "intermediary function" in this case is just PHPTemplate's theme function implementation. Couldn't we solve this by having the "stub" function usually in template.php just *be* the theme_ function? That is instead of: Your module: function theme_foo($bar) { return '<p> This themes '. $bar .'</p>'; } Your theme's template.php: function phptemplate_foo($bar) { $variables = array( 'bar' => $bar, ); return _phptemplate_callback('foo', $variables); } you would just have Your module: function theme_foo($bar) { $variables = array( 'bar' => $bar, ); return _phptemplate_callback('foo', $variables); }
On 04 May 2006, at 3:10 PM, Jonathan Chaffer wrote:
Your module: function theme_foo($bar) { $variables = array( 'bar' => $bar, ); return _phptemplate_callback('foo', $variables); } Actually : The 'phptemplate' part of it is not necessarily true.
With META INFORMATION the theme engine doesn't have to have a _templates() hook, which means it can just tell system_listing what extension to search for to find templates. (ie: *.tpl.php, or *.tal). This was one of the first places I wanted to introduce meta- information but later removed it at Dries' request. Every single contrib theme engine (except perhaps xtemplate) is a copy paste job from phptemplate, re-implementing perhaps a max of 2 functions. Originally I had 3 namespaces. 1 : theme_ : what drupal ships with. 2 : engine_ : ie what phptemplate_node and phptemplate_page should have been (engine_node, engine_page) 3 : template_ : instead of having $themename_ functions, all of them were centralised under template_ This all works, because in my design you should never have multiple theme engines, or multiple themes loaded at the same time. I built the theme engine system initially to have this level of abstraction in core, but when it wasn't accepted, i moved it into phptemplate. 'phptemplate' it self is just this code : function _phptemplate_render($file, $variables) { extract($variables, EXTR_SKIP); // Extract the variables to a local namespace ob_start(); // Start output buffering include "./$file"; // Include the file $contents = ob_get_contents(); // Get the contents of the buffer ob_end_clean(); // End buffering and discard return $contents; // Return the contents } The useful part of phptemplate is the variable collection and filtering semantics. If all the rest of phptemplate is moved into core as engine_ functions, and we nothing else. most other template engines can be implemented by just creating _phptal_render($file, $variables) or whatever. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Adrian Rossouw wrote:
With META INFORMATION the theme engine doesn't have to have a _templates() hook, which means it can just tell system_listing what extension to search for to find templates. (ie: *.tpl.php, or *.tal).
Yeah, that'd be quite nice. +1! ;)
This all works, because in my design you should never have multiple theme engines, or multiple themes loaded at the same time.
+1 on this, too.
This was one of the first places I wanted to introduce meta- information but later removed it at Dries' request.
Correction: I was merely questioning the usefulness of having separate files with meta-information, not rejecting it. Prove me that (i) it is really useful and (ii) the easiest way to tackle the problem and I'm convinced. (Moste did a pretty good job convincing me.) In this particular case, the question still stands: does this template extension need to be in a separate meta-information file, or can it be returned by a function in the engine/theme file? I don't see why it needs to be in a file with meta-information ... -- Dries Buytaert :: http://buytaert.net/
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
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.
If we remove the theme_ function (but still allow them to be used for those who want to), does that mean that PHPTemplate becomes the default fall-back? If I'm using Smarty, and the designer has chosen not to overwrite/reimplement a particular PHPTemplate, we'd still have to load and use the PHPTemplate engine? Similarly, if I don't want to use PHPTemplate, I'd have to overwrite all theme functions? If PHPTemplate is not the default fall-back, this change would create a lot of duplication. Or am I wrong? -- Dries Buytaert :: http://buytaert.net/
Jeremy Epstein wrote:
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).
I'm one of those puritans using a PHP theme (delocalized.theme, it is even in contrib, but no project page for it). I'm using a PHP theme because there are some ways PHPTemplate simply doesn't work: - I want to decide my block regions, not have PHPTemplate tell me which ones I implement. (Or better yet, I just want to put regions in my template and have something else figure out what they are.) - I want to decide my theme features, not have PHPTemplate tell me which ones I implement. (Or, better yet, I just don't want to have to worry about them.) - I can just copy themeable functions into my theme and go. But all these (especially the last) will have to be fixed if PHPTemplate is the default. As for multiple themeing systems being a strength, I would really like to see hard statistics showing just how often PHPTemplate is used. If it is really high, I'd take the ability to do things that would otherwise break the engine layer and have the simplification of not having an engine layer over a check mark on the feature list. -- Neil Drumm http://delocalizedham.com/
Neil Drumm wrote:
I'm using a PHP theme because there are some ways PHPTemplate simply doesn't work:
- I want to decide my block regions, not have PHPTemplate tell me which ones I implement. (Or better yet, I just want to put regions in my template and have something else figure out what they are.)
function delocalized_regions() { return array(...stuff...); }; // Done.
- I want to decide my theme features, not have PHPTemplate tell me which ones I implement. (Or, better yet, I just don't want to have to worry about them.)
Not sure about this one. It may be a weakness of the current engine system, or there may be a way to do it that I don't know yet.
- I can just copy themeable functions into my theme and go.
I do that in my template.php all the time.
But all these (especially the last) will have to be fixed if PHPTemplate is the default.
As for multiple themeing systems being a strength, I would really like to see hard statistics showing just how often PHPTemplate is used. If it is really high, I'd take the ability to do things that would otherwise break the engine layer and have the simplification of not having an engine layer over a check mark on the feature list.
Well, it's used every time someone installs 4.7 ...
On 04 May 2006, at 9:22 PM, Earl Miles wrote:
As for multiple themeing systems being a strength, I would really like to see hard statistics showing just how often PHPTemplate is used. If it is really high, I'd take the ability to do things that would otherwise break the engine layer and have the simplification of not having an engine layer over a check mark on the feature list. It's a good feature to have. And it's only a re-implementation of 1 function 99% of the time. The only time it isn't is with xtemplate like engines.
-- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
On 04 May 2006, at 9:05 PM, Neil Drumm wrote:
- I want to decide my block regions, not have PHPTemplate tell me which ones I implement. (Or better yet, I just want to put regions in my template and have something else figure out what they are.)
If we had meta information, you could have a section in your theme meta info document for regions ie: regions: left, right, bottom, top, green, spatula
- I want to decide my theme features, not have PHPTemplate tell me which ones I implement. (Or, better yet, I just don't want to have to worry about them.) if we had meta information, you could have a section in your theme meta info document for features.
ie: supports : toggle_something, site_name, something_else I wasn't fond of the fact that these things were given hooks in the first place, and these types of settings are ideal for metadata files.
- I can just copy themeable functions into my theme and go. Normal people could just copy the template file into their template directory and go. You could still copy the contents of the template file into a theme function :
function mytheme_something($var, $var, $var) { ?> <?php } -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
Op donderdag 4 mei 2006 21:05, schreef Neil Drumm:
As for multiple themeing systems being a strength, I would really like to see hard statistics showing just how often PHPTemplate is used. If it is really high, I'd take the ability to do things that would otherwise break the engine layer and have the simplification of not having an engine layer over a check mark on the feature list.
What if we pull this "layer" down into the module section? An engine would be just another module. I love that concept, for it removes a big piece of themeing complexity from the system. Bèr
On 08 May 2006, at 11:01 AM, Bèr Kessels wrote:
What if we pull this "layer" down into the module section? An engine would be just another module. I love that concept, for it removes a big piece of themeing complexity from the system.
I don;t know. This is one of those things i think should be a 'library' which is what the current system aproximates. I don't believe the user should need to go enable the template engine support module to have it be able to pick up themes. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com
participants (8)
-
Adrian Rossouw -
Bèr Kessels -
Dries Buytaert -
Earl Miles -
Jeremy Epstein -
Jonathan Chaffer -
Neil Drumm -
Rowan Kerr