[development] Strip out theme functions into a .theme file

[Bèr Kessels]

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 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060804/b90f9443/attachment.pgp