[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