Now that we have modules in their own directories, I think we could move forward to ease pain for designers by stripping out theme functions out of the .module file into a .theme file. We already did the same for installation, and there's currently a patch in the queue to do the same for help files. Why we should move theme_* functions into a <modulename>.theme file: * ease pain for designers. Currently, they have to look through all the module code, that is not interesting for them at all, to find a theme function they want to overwrite. By having them all together in a <modulename>.theme file, it will save a lot of time and effort for them. And IMO we should take a bit more care of them, especially if it does not hurt at all. * Seperation of code and design has always been a main target. So I think it's only logical to stick to this policy here and move the V part of a module into a different file than the C part (according to the MVC pattern) best regards, Frando
I think Adrian has proposed/is working on just that. The only difference is that he wants each theme function in a file on its own (to which I have a concern about performance). Adrian, any updates on this? On 7/29/06, Frando (Franz Heinzmann) <frando@xcite-online.de> wrote:
Now that we have modules in their own directories, I think we could move forward to ease pain for designers by stripping out theme functions out of the .module file into a .theme file.
We already did the same for installation, and there's currently a patch in the queue to do the same for help files.
Why we should move theme_* functions into a <modulename>.theme file:
* ease pain for designers. Currently, they have to look through all the module code, that is not interesting for them at all, to find a theme function they want to overwrite. By having them all together in a <modulename>.theme file, it will save a lot of time and effort for them. And IMO we should take a bit more care of them, especially if it does not hurt at all.
* Seperation of code and design has always been a main target. So I think it's only logical to stick to this policy here and move the V part of a module into a different file than the C part (according to the MVC pattern)
best regards, Frando
My mac died this weekend, but now that I have finished with DrupalCamp Johannesburg, I will have some time to work on this again. We can make a patch now, which we couldn't have done before modules had their own dirs. On 7/29/06, Khalid B <kb@2bits.com> wrote:
I think Adrian has proposed/is working on just that.
The only difference is that he wants each theme function in a file on its own (to which I have a concern about performance).
Adrian, any updates on this?
On 7/29/06, Frando (Franz Heinzmann) <frando@xcite-online.de> wrote:
Now that we have modules in their own directories, I think we could move forward to ease pain for designers by stripping out theme functions out of the .module file into a .theme file.
We already did the same for installation, and there's currently a patch in the queue to do the same for help files.
Why we should move theme_* functions into a <modulename>.theme file:
* ease pain for designers. Currently, they have to look through all the module code, that is not interesting for them at all, to find a theme function they want to overwrite. By having them all together in a <modulename>.theme file, it will save a lot of time and effort for them. And IMO we should take a bit more care of them, especially if it does not hurt at all.
* Seperation of code and design has always been a main target. So I think it's only logical to stick to this policy here and move the V part of a module into a different file than the C part (according to the MVC pattern)
best regards, Frando
I started working on this a bit. I wrote a little script that uses some regular expressions to remove all theme functions from the .module files and put theme into a .theme file. This .theme file is included at the beginning of all .module files that have a .theme file. More details and the extractor script can be found at the issue: http://drupal.org/node/76596 It's working greatly for me so far, I haven't found any bugs yet. Some reviews would be appreciated. I'd really like to get this into 4.8. Regards, frando
I wrote a little script that uses some regular expressions to remove all theme functions from the .module files and put theme into a .theme file. This .theme file is included at the beginning of all .module files that have a .theme file.
Wouldn't it make more sense to include the theme only when it's needed? That way, we get a slight speedup when we do things that don't 'em (like _help, nodeapi calls that only add to node but not modify it, etc.). Actually, I'm wondering if we could hook that into theme() - if the passed theme isn't in memory, load all theme files to look for it. If we demand proper namespaces on the theme's names, we can then only load the actual namespace'd file. -- Morbus Iff ( softcore vulcan pr0n rulezzzzz ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On Thu, August 3, 2006 9:27 am, Morbus Iff said:
I wrote a little script that uses some regular expressions to remove all theme functions from the .module files and put theme into a .theme file. This .theme file is included at the beginning of all .module files that have a .theme file.
Wouldn't it make more sense to include the theme only when it's needed? That way, we get a slight speedup when we do things that don't 'em (like _help, nodeapi calls that only add to node but not modify it, etc.).
Actually, I'm wondering if we could hook that into theme() - if the passed theme isn't in memory, load all theme files to look for it. If we demand proper namespaces on the theme's names, we can then only load the actual namespace'd file.
I would actually take it a ste further than that. A few months ago there was discussion of one-file-per-template, which would make them easier for themes to override. In light of that I put together a patch for manipulating CSS files that does exactly that[1]. Unfortunately another patch submitted at around the same time [2] just went in instead (I think it's overly heavy, but Dries apparently disagrees), but I still think the idea is sound and can work for theme/template files just as well. Consider: - We already have one single namespace for themes, so we needn't worry about them all being in a single namespace. Nothing would break that isn't already broken. - Most pages views use only a small number of the theme files available in the system. So, I'd propose replacing theme_foo() with foo.theme. Such files would simply be packaged with their corresponding module, now that we have all modules in their own directories (yay!). Upon viewing the admin/modules page, the system would index not only .module files but .theme files in the system table. Then, when theme('foo', $bar, $baz) is called, the theme system simply looks up the corresponding file and includes it, then returns the output. The theme() API remains unchanged. Advantages: - Fewer functions to parse that won't actually get used = improved performance. - Themers can know what theme "functions" they have available to override simply by looking at the module's directory. Anything that ends in .theme is an overridable theme function. - To override theme "function" foo in a theme, just create foo.theme in your theme directory. It automagically replaces the module-provided one, just as in the CSS patch[1]. - As someone (Adrian? I don't recall) pointed out to me when the subject first came up, you can still use PHP-centric code in such files. If it's a function that needs to be programmatic (eg, theme_table()), just switch into PHP mode with <?php on the first line and Bob's your third cousin twice removed. - Whether a given theme function is programmatic or template-based can easily vary depending on the needs of the given function and the preference of the author. - Generic theme functions (theme_table(), etc.) can be adopted by system.module. The rest of the system won't care. Concerns: - I'm not sure what the performance cost would be for including each theme file, especially those that are included multiple times. (How many are there that get included several times?) The reduced parsing cost could offset it, or PHP could cache smartly, or something else. We'd need to try it and benchmark it. - I've not worked with template engines other than PHPTemplate, so I'm not sure how those would be handled. We'd need to make sure that Smarty, PHPTal, etc. still worked properly. - Because this would conceivably do away with the extra layer of callback function in template.php, there may be needed functionality there that would need to move elsewhere, either into the .theme file or into the function that is calling it. Thoughts? /me dons flame-retardant suit and prepares for his roasting. [1] http://drupal.org/node/73949 [2] http://drupal.org/node/73961 --Larry Garfield
So, I'd propose replacing theme_foo() with foo.theme. Such files would
For what it's worth, I'm against file-per-function, but don't have time to get into it further right now. Maybe later. If you hit me up on IRC, I can explain faster ;) -- Morbus Iff ( if god is my witness, god must be blind ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 8/3/06, Morbus Iff <morbus@disobey.com> wrote:
So, I'd propose replacing theme_foo() with foo.theme. Such files would
For what it's worth, I'm against file-per-function, but don't have time to get into it further right now.
I am concerned about a file per function too, from the sheer number of .theme files that we will have (clutter) and their possible impact on performance. Adrian seems to think it is not a performance issue though.
Adrian seems to think it is not a performance issue though.
Imagine you have 15 activated modules. Every module has 2 theme functions, which makes it 30 fopen() calls for every page load. This IS performance issue. -- Jakub Suchý <jakub.suchy@logios.cz> web: http://www.logios.cz
On Thu, August 3, 2006 1:32 pm, Jakub Suchy said:
Adrian seems to think it is not a performance issue though.
Imagine you have 15 activated modules. Every module has 2 theme functions, which makes it 30 fopen() calls for every page load. This IS performance issue.
That's assuming that you use all 30 theme functions on every page. You may only use 4-5. Remember that the most frequently-used theme functions are those that are already setup as separate files via the template engine: page, node, block, etc. I'm open to suggestions on how to properly benchmark what the performance difference would be here. --Larry Garfield
Also. the way the code works at present is that it creates anonymous functions in php, with the contents of the file, and then caches those. We got it to within 5-10% of drupal core performance, but the biggest issue was theme_link. I'm not even altogether convinced theme_link (or theme_table for that matter) should be theme functions. ALSO.. since we are doing this to be friendly to designers, moving them all to a single .theme file is still nowhere near as friendly as just 'copy this file to your theme directory to override'. Doing it this way means you never have to write silly phptemplate stubs again, something which shouldn't have been necessary in the first place. On 8/3/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Thu, August 3, 2006 1:32 pm, Jakub Suchy said:
Adrian seems to think it is not a performance issue though.
Imagine you have 15 activated modules. Every module has 2 theme functions, which makes it 30 fopen() calls for every page load. This IS performance issue.
That's assuming that you use all 30 theme functions on every page. You may only use 4-5. Remember that the most frequently-used theme functions are those that are already setup as separate files via the template engine: page, node, block, etc.
I'm open to suggestions on how to properly benchmark what the performance difference would be here.
--Larry Garfield
On 03 Aug 2006, at 20:32, Jakub Suchy wrote:
Adrian seems to think it is not a performance issue though.
Imagine you have 15 activated modules. Every module has 2 theme functions, which makes it 30 fopen() calls for every page load. This IS performance issue.
There is lots of subtle trade-offs involved (eg. less PHP parsing, smaller memory footprint, but more fopen() calls) and it is hard to predict how these level out. Let's not make claims and just benchmark it? We did some preliminary benchmarks and noticed a 10% performance cost. This cost was not caused by fopen() but by the way variables were handled. This might be less of an issue with this patch. It's well worth exploring this further, IMO, but rather than guessing we should collect factual data. -- Dries Buytaert :: http://www.buytaert.net/
Op vrijdag 4 augustus 2006 12:23, schreef Dries Buytaert:
We did some preliminary benchmarks and noticed a 10% performance cost. This cost was not caused by fopen() but by the way variables were handled. This might be less of an issue with this patch.
It's well worth exploring this further, IMO, but rather than guessing we should collect factual data.
Something that is *very* important when benching fopens-freads is the underlying file system and the activity of the HD. I was told that a fopen - fread (php include() ) often does a file lock too. On a server where there is a lot of disc activity this may idle your app for seconds or even longer, since PHP will idle/wait untill it may actually open the file. So in short: make sure you benchmark this on a system that is apropriate. simply benchmarking it on a single site on your localhost will not suffice! -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
well. additionally the code from the templates might even be cached to the db (we actually had this implemented already) an opcode cache would make this unneeded though. On 8/4/06, Bèr Kessels <ber@webschuur.com> wrote:
Op vrijdag 4 augustus 2006 12:23, schreef Dries Buytaert:
We did some preliminary benchmarks and noticed a 10% performance cost. This cost was not caused by fopen() but by the way variables were handled. This might be less of an issue with this patch.
It's well worth exploring this further, IMO, but rather than guessing we should collect factual data.
Something that is *very* important when benching fopens-freads is the underlying file system and the activity of the HD.
I was told that a fopen - fread (php include() ) often does a file lock too. On a server where there is a lot of disc activity this may idle your app for seconds or even longer, since PHP will idle/wait untill it may actually open the file.
So in short: make sure you benchmark this on a system that is apropriate. simply benchmarking it on a single site on your localhost will not suffice!
-- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
Doing good benchmarks is the right way to determine the impact of this kind of change. And as Bèr says, the kind and use of the system upon which the benchmark runs is important. Although I am 95% sure fopen() does not do any kind of locking, his point is still valid. Note also that any decent filesystem is going to be caching file handles (directories and inodes on most *nix filesystems), so repeated openings of the same files is way fast compared to the first open off disk. Such a variable is yet another reason to benchmark and to describe well the host situation under which the benchmark was run. I'm glad to see so much activity on improving Drupal's performance! Adrian Rossouw wrote:
well. additionally the code from the templates might even be cached to the db (we actually had this implemented already)
an opcode cache would make this unneeded though.
On 8/4/06, *Bèr Kessels* <ber@webschuur.com <mailto:ber@webschuur.com>> wrote:
Op vrijdag 4 augustus 2006 12:23, schreef Dries Buytaert: > We did some preliminary benchmarks and noticed a 10% performance > cost. This cost was not caused by fopen() but by the way variables > were handled. This might be less of an issue with this patch. > > It's well worth exploring this further, IMO, but rather than guessing > we should collect factual data.
Something that is *very* important when benching fopens-freads is the underlying file system and the activity of the HD.
I was told that a fopen - fread (php include() ) often does a file lock too.
On Thu, August 3, 2006 1:11 pm, Khalid B said:
On 8/3/06, Morbus Iff <morbus@disobey.com> wrote:
So, I'd propose replacing theme_foo() with foo.theme. Such files would
For what it's worth, I'm against file-per-function, but don't have time to get into it further right now.
I am concerned about a file per function too, from the sheer number of .theme files that we will have (clutter) and their possible impact on performance.
Adrian seems to think it is not a performance issue though.
As I said, I'm not sure what the performance trade-off would be without actually benchmarking it. I'm just remembering chx's split mode patch, which seemed a net win (trading parsing time for disk IO). Think of this as "pre-done split mode" for themes. :-) --Larry Garfield
* and then Frando (Franz Heinzmann) declared....
* Seperation of code and design has always been a main target. So I think it's only logical to stick to this policy here and move the V part of a module into a different file than the C part (according to the MVC pattern)
Just getting developers to make sure tables and other html elements have unique id's or classes would be wonderful -- im all for this, but i think it would be beneficial if some of the theming functions *required* these optional attributes. -- Nick Wilson http://performancing.com/user/1
Op donderdag 3 augustus 2006 19:37, schreef Nick Wilson:
Just getting developers to make sure tables and other html elements have unique id's or classes would be wonderful -- im all for this, but i think it would be beneficial if some of the theming functions *required* these optional attributes.
We had a long thread abotu this when I tried to introduce exactly this in a theme_wrapper() http://drupal.org/node/23584 I hoped that would become a general "add some HTML around this string" function. It enforced unique IDs and allowed nice classes. But it seems the community is split when it comes to this: developers want to include only the IDs and CLASSes they need for their case: fair enough. The themers part of the community has been begging for some guidelines in IDs and classes for ages. For that latter group I decided that we need to do this on the theme level: its "our" domain ;) I therefore aim at, what I call brickslate, an engine that makes sure you receive proper IDs and CLASSes, consistently names, in nice, useful and clean HTML. The first step towards this can already be seen in the phptemplate theme whatisinitsname: http://cvs.drupal.org/viewcvs/drupal/contributions/themes/whatsinitsname/ and http://webschuur.com/taxonomy/term/65 I am now finishing up the first theme I built on top of this frame, and so far I am impressed. I designed a pure CSS theme with only CSS, with hardly ever changing the actual HTML I outputted, and I found the naming iof the IDs and classes very easy to grok and remember. But I will refrain from releasing anything, untill I have build more themes on this base. With this you can help, by using it and giving feedback :) After all "the proof of the pudding is in the eating" (or so) Once I am happy with this whatsinitsname theme, I want to move it a step further: fork/rewrite PHPtemplate so it outputs this stuff by default, and makes it a lot more consistent and easier: brickslate. I suspect that if we get such a theme system running properly and get it sorted out to be the perfect HTML generator after some time, that thatwill trickle back into core and contribs. Then contribs and core can start to follow the consistent naming conventions we introduced! Bèr -- | Bèr Kessels | webschuur.com | Drupal, Joomla and Ruby on Rails web development | | Jabber & Google Talk: ber@jabber.webschuur.com | | http://bler.webschuur.com | http://www.webschuur.com |
There are a few reasons I'm against theme functions as their own file, but first, let me clarify exactly what I'm talking about: * Good: /modules/user/user.theme * Bad: /modules/user/themes/user_picture.theme * Good: /themes/themename/template.php * Bad: /themes/themename/user_picture.tpl.php Also note that: * I will NOT care about user_picture.tpl.php IF I can /continue/ to do what I've been doing with my template.php. I see no reason why we can't support both at the same time. Shut me up by continuing to support both! ;) Reasons why I dislike one-theme-function-per-file: * It promotes poor logic vs. design. A lot of our theme functions have plenty of logic in them like, say, theme_user_picture. * It promotes weaker code. A designer who knows nothing about Drupal or coding is going to see "theme('image' ...)", wonder what the hell it is, and change that to an <img> tag instead. * It harms oneliners. There are a lot of times where I don't need to retheme an /entire/ function, but just one small aspect of it. Making a new file for one line of code is ugly: // in file example.tpl.php. <?php print str_replace('monkey', 'ape', theme_example()); ?> Another example of a theme oneliner that doesn't deserve to be it's own file is theme_placeholder. * The template.php is great for organizational purposes, especially when you can split them into template.forum.php, template.user.php, and so forth. This approach is much stronger then theme files because it also allows you to create new custom routines and have the code as close to its relevance as possible (I routinely create and make _is_forum().). It also keeps everything in one place - it's far easier to open up one file and browse through comments or code then it is to open, and close, 20 files, or to force the overhead of a new module (on the designer!) just to create an _is_forum(). Likewise, themes per file make it difficult to do different types of theming depending on different types of pages. Previously, I could do some logic in template.php, then load template.user.php or template.forum.php (which could have duplicate, but different, declarations of a single theme function). This kept all my determining logic in one place. With themes as files, I now have to move my logic to each and every individual file. * Aesthetically, 30 files in a directory is "harder" to mentally parse than knowing exactly where to go (template.php). I just don't find it pleasing at all, and it violates my codeshui love. Mixing multiple /types/ of theme files (we already have a disconnect between page.tpl.php, node.tpl.php, and the mysterious box.tpl.php) can also be confusing. What's node.tpl.php do in regards to node_list.tpl.php? Why would a designer, who probably DOESN'T have administrative access, theme or even see node_search_admin.tpl.php. * I will agree that themes as files are easier for a /novice/ designer. However, I feel that it entirely screws /advanced/ theme developers, when there's no reason for it too. The easiest way to solve all my complaints is to let theming remain as it is now, but get a "new" and optional feature of themes as files. The module developer can decide between modulename.theme or theme/, and the theme designer can make the same choice - if a file doesn't exist, look for it in memory via template.php or what have you. This mixture I could see quite useful - I'm nearly finished a rather large site that does a lot with Member Profiles, and I did force a profile_listing.tpl.php via template_file modifications in template.php. If I could do what I normally do, but get that optional feature for free, I'd be happy. -- Morbus Iff ( god less america ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
I too am sceptical about breaking every theme function into its own file. Are we really considering going from pager.inc (one file) to: pager.inc, pager.theme, pager_first.theme, pager_previous.theme, pager_next.theme, pager_last.theme, pager_list.theme and pager_link.theme (8 files)? And I'm sure other theme functions are as complicated as pager. If not now, something will come along in the future. -Dave On Friday 04 August 2006 04:46, Morbus Iff wrote:
Also note that:
* I will NOT care about user_picture.tpl.php IF I can /continue/ to do what I've been doing with my template.php. I see no reason why we can't support both at the same time. Shut me up by continuing to support both! ;)
A lot of words for a simple statment: "Hello I am a coder who know his HTML". I, being not coder nor designer, but merely a monkey, know from (some) experience with lots of *designers* that the following is Simply a True Fact: <?php if ($foo) { print '<p>bar:'. $bar .'</p>'; } ?> Is considerd HARD and the other one: <?php if($foo) { ?> <p>bar: <?php print $bar ?></p> <?php } ?> ?> is considered EASY. yes: the first one performs better. And yes, the first one and the second one (provided my late night typing errors) do the same. But consider one simple fact: the H in PHP: Hypertext. PHP was meant to solve the issues the way I present it in the second piece. C(++) can do the first example. So can Perl, and probably about every language out there. The only important fact why PHP became what it is today (probably the reason why you are reading my mail on this mailinglist in the first place) is because PHP managed to fill the gap by allowing HTML savvy people to start coding. So no: I disagree with Morbus, and I think that themes with loads and loads of *consistent* xyz.tpl.php files are the way forward. and that template.php is nice, but only to fill the gaps that are not (yet) filled xyz.tpl.php files! I believe that template.php is fine to solve your urgent matters, but that a solid theme whould/will consist of almost only (one liners) tpl.php files! Bèr Op vrijdag 4 augustus 2006 13:46, schreef Morbus Iff:
There are a few reasons I'm against theme functions as their own file, but first, let me clarify exactly what I'm talking about:
* Good: /modules/user/user.theme * Bad: /modules/user/themes/user_picture.theme
* Good: /themes/themename/template.php * Bad: /themes/themename/user_picture.tpl.php
Also note that:
* I will NOT care about user_picture.tpl.php IF I can /continue/ to do what I've been doing with my template.php. I see no reason why we can't support both at the same time. Shut me up by continuing to support both! ;)
Reasons why I dislike one-theme-function-per-file:
* It promotes poor logic vs. design. A lot of our theme functions have plenty of logic in them like, say, theme_user_picture.
* It promotes weaker code. A designer who knows nothing about Drupal or coding is going to see "theme('image' ...)", wonder what the hell it is, and change that to an <img> tag instead.
* It harms oneliners. There are a lot of times where I don't need to retheme an /entire/ function, but just one small aspect of it. Making a new file for one line of code is ugly:
// in file example.tpl.php. <?php print str_replace('monkey', 'ape', theme_example()); ?>
Another example of a theme oneliner that doesn't deserve to be it's own file is theme_placeholder.
* The template.php is great for organizational purposes, especially when you can split them into template.forum.php, template.user.php, and so forth. This approach is much stronger then theme files because it also allows you to create new custom routines and have the code as close to its relevance as possible (I routinely create and make _is_forum().). It also keeps everything in one place - it's far easier to open up one file and browse through comments or code then it is to open, and close, 20 files, or to force the overhead of a new module (on the designer!) just to create an _is_forum().
Likewise, themes per file make it difficult to do different types of theming depending on different types of pages. Previously, I could do some logic in template.php, then load template.user.php or template.forum.php (which could have duplicate, but different, declarations of a single theme function). This kept all my determining logic in one place. With themes as files, I now have to move my logic to each and every individual file.
* Aesthetically, 30 files in a directory is "harder" to mentally parse than knowing exactly where to go (template.php). I just don't find it pleasing at all, and it violates my codeshui love. Mixing multiple /types/ of theme files (we already have a disconnect between page.tpl.php, node.tpl.php, and the mysterious box.tpl.php) can also be confusing. What's node.tpl.php do in regards to node_list.tpl.php? Why would a designer, who probably DOESN'T have administrative access, theme or even see node_search_admin.tpl.php.
* I will agree that themes as files are easier for a /novice/ designer. However, I feel that it entirely screws /advanced/ theme developers, when there's no reason for it too.
The easiest way to solve all my complaints is to let theming remain as it is now, but get a "new" and optional feature of themes as files. The module developer can decide between modulename.theme or theme/, and the theme designer can make the same choice - if a file doesn't exist, look for it in memory via template.php or what have you. This mixture I could see quite useful - I'm nearly finished a rather large site that does a lot with Member Profiles, and I did force a profile_listing.tpl.php via template_file modifications in template.php. If I could do what I normally do, but get that optional feature for free, I'd be happy.
-- [ Bèr Kessels | Drupal services www.webschuur.com ] Layoutkeuze, de stap voordat je gaat (laten) ontwerpen.: http://help.sympal.nl/layoutkeuze_de_stap_voordat_je_gaat_laten_ontwerpen Written while listening to by on
A lot of words for a simple statment: "Hello I am a coder who know his HTML".
Uh. No.
So no: I disagree with Morbus, and I think that themes with loads and loads of
You chose something *I didn't mention at all* to disagree with me about. I could care two donuts (Note: Morbus' original phrase has been edited to protect all the thin-skins on the list. --Editor) about whether it's PHP with prints, or PHP with syntactic sugar within <?php ?> only. That's not what I'm arguing.
*consistent* xyz.tpl.php files are the way forward. and that template.php is nice, but only to fill the gaps that are not (yet) filled xyz.tpl.php files! I believe that template.php is fine to solve your urgent matters, but that a solid theme whould/will consist of almost only (one liners) tpl.php files!
I don't believe you countered each and every one of my points, so until you do, I won't bother reiterating them. Suffice to say, I disagree, and please reread why. -- Morbus Iff ( relax have a happy meal ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
* and then Bèr Kessels declared....
Op donderdag 3 augustus 2006 19:37, schreef Nick Wilson:
Just getting developers to make sure tables and other html elements have unique id's or classes would be wonderful -- im all for this, but i think it would be beneficial if some of the theming functions *required* these optional attributes.
We had a long thread abotu this when I tried to introduce exactly this in a theme_wrapper() http://drupal.org/node/23584 I hoped that would become a general "add some HTML around this string" function. It enforced unique IDs and allowed nice classes.
That looks to be a near perfect fix, particularly as it's so clean and quick.
But it seems the community is split when it comes to this: developers want to include only the IDs and CLASSes they need for their case: fair enough. The themers part of the community has been begging for some guidelines in IDs and classes for ages.
I can't see the dev's point of view here. Having to supply an additional class name or two seems a very small price to pay for giving the designers a whole heap more flexibility and making Drupal easier to work with.
For that latter group I decided that we need to do this on the theme level: its "our" domain ;) I therefore aim at, what I call brickslate, an engine that makes sure you receive proper IDs and CLASSes, consistently names, in nice, useful and clean HTML. The first step towards this can already be seen in the phptemplate theme whatisinitsname: http://cvs.drupal.org/viewcvs/drupal/contributions/themes/whatsinitsname/ and http://webschuur.com/taxonomy/term/65
Am i understanding you right, that this uses theme_wrapper()?
I am now finishing up the first theme I built on top of this frame, and so far I am impressed. I designed a pure CSS theme with only CSS, with hardly ever changing the actual HTML I outputted, and I found the naming iof the IDs and classes very easy to grok and remember. But I will refrain from releasing anything, untill I have build more themes on this base. With this you can help, by using it and giving feedback :) After all "the proof of the pudding is in the eating" (or so)
I'm planning on doing just that. But here's something to think about: phptemplate is messy, mixing html with php -- actually, i find phptemplate truly horrid, and only work with it if i have too -- if you're tying to get drupal to be cleaner coded, why not use the Smarty engine instead of phptemplate aswell?
I suspect that if we get such a theme system running properly and get it sorted out to be the perfect HTML generator after some time, that thatwill trickle back into core and contribs. Then contribs and core can start to follow the consistent naming conventions we introduced!
Sounds good, but i think just the enforcement of theme_wrapper() would be the best way forward as it's clean and quick and really doesn't require a great deal more effort from devs... -- Nick Wilson http://performancing.com/user/1
Nick Wilson :
* and then Bèr Kessels declared....
I am now finishing up the first theme I built on top of this frame, and so far I am impressed. I designed a pure CSS theme with only CSS, with hardly ever changing the actual HTML I outputted, and I found the naming iof the IDs and classes very easy to grok and remember. But I will refrain from releasing anything, untill I have build more themes on this base. With this you can help, by using it and giving feedback :) After all "the proof of the pudding is in the eating" (or so)
I'm planning on doing just that. But here's something to think about: phptemplate is messy, mixing html with php -- actually, i find phptemplate truly horrid, and only work with it if i have too -- if you're tying to get drupal to be cleaner coded, why not use the Smarty engine instead of phptemplate aswell?
Like here : http://gallery.menalto.com/node/31167 You mean that you prefer <?php print $var ?> vs. {$var} and you claim "PHP is too complicated for web designers. They just want HTML!". :)) Emphasing http://www.massassi.com/php/articles/template_engines/ I'll say "In short, the point of template engines should be to separate your business logic from your presentation logic, not separate your PHP code from your HTML code." And there, phpTemplate is far superior to smarty. Jeremy and Adrian already gave interesting args on that months ago.. See http://lists.drupal.org/archives/development/2006-05/msg00248.html & http://lists.drupal.org/archives/development/2006-05/msg00255.html Excuse, but Drupal did it the right way by choosing phpTemplate.. -- http://drupal.org/node/68827
participants (12)
-
Adrian Rossouw -
Bèr Kessels -
Chris Johnson -
Dave Cohen -
Dries Buytaert -
Frando (Franz Heinzmann) -
Gildas Cotomale -
Jakub Suchy -
Khalid B -
Larry Garfield -
Morbus Iff -
Nick Wilson