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