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

Morbus Iff morbus at disobey.com
Fri Aug 4 11:46:35 UTC 2006


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


More information about the development mailing list