Token Templates: a new template engine for Drupal

After an on-site training in Washington DC teaching HTML and CSS experts how to build Drupal theme, Carl and I wondered why building themes for Drupal had become so difficult.

We talked about what theme developers actually wanted to do, and pondered the tools provided by Drupal. There was an obvious mismatch. The tools provided to for writing HTML and CSS are written by people who are trying to avoid writing HTML and CSS. We concluded that PHP theme() function is not the right answer.

We looked into the past, at what other theme engines (like smarty) provided. We looked at the present state of Drupal 7 theme development, with it's use of PHP functions like hide() and render(). We looked at the places where people struggled with the complex data structures provided for output, and were tempted to pull unsanitized data directly from the $node object.

Maybe the answer lies with tokens. Can we create template files that contain only HTML and placeholders? Can these placeholders provide sanitized output to the theme layer, at whatever level of granularity is requested, and only when requested?

If you like your HTML and CSS to be clean, how would you feel about a node template file that looked like this:

<div id="node-[node:nid]">

  <div class="meta submitted">
    [node:author:picture]
    Submitted by <a href="[node:author:url]">[node:author]</a> on [node:created:custom:m/d/Y]
  </div>

  <div class="content clearfix">
    [node:body]
    <div class="tags">Tags: [node:field_tags]</div>
  </div>

  <div class="link-wrapper">[node:links]</div>

  [node:comments]

</div>

It's all possible. Come to this session to see a working example of our tokentemplate theme engine, and debate the pros and cons of this approach. Let's figure out how to simplify Drupal's template files so HTML and CSS experts feel they have a place here too.

Room: 
Track: 
Coding and development
Experience level: 
Intermediate
Questions answered by this session: 
How can we make building themes less daunting for newcomers to Drupal?
How can we provide people who write HTML and CSS with the tools they actually want to build themes?
How can we keep complex data structures and confusing PHP functions out of template files?
How can we provide sanitized output for use in the theme layer?
How can we improve Drupal's rendering speed?

Comments

I can't wait to get my hand on this engine.

1) Drupal's token system was not designed for this. I will repeat this all over again. Just to make sure that security vulnerability hell that's going to result of any change like this was known upfront.

2) There's no differentiation between HTML and HTML attributes and plain text.

3) "Delayed rendering on demand" doesn't ultimate hold water, stuff is still built and prepared and whatnot to appear as a template variable in the first place.

4) Before we even attempt to go down this path, let's completely forget about the PHPTemplate engine and simply investigate and use a different one that has these kind of patterns and features built-in.

I'm not saying this approach is the right answer. But it's an interesting perspective to examine.

This may not be what tokens were meant for, and they might not be the right tool for the job. But they do solve* at least two problems: syntax, and performance. Plus - we already have them!

It would be good to think outside the box rather than looking at other theme engines (I think PHPTemplate already won that battle) and see what hidden gems we may already use that could be incorporated with what we already know.

While I think sun raises some valid points, I also believe that it's important to keep an open mind and while this might not be a perfect solution, it can be a good step toward one or at least stimulate dialog and thinking about ways that we can provide better theming tools to people who don't know (much) PHP, but are comfortable with HTML (and possibly CSS), so I'm looking forward to this session and to whatever comes from exploring alternatives.

BTW, I suspect something went wrong with this sentence (from the current session description)... this doesn't quite make sense:

The tools provided to for writing HTML and CSS are written by people who are trying to avoid writing HTML and CSS. We concluded that PHP theme() function is not the right answer.

<?php
  $full_name
= 'Lowell Montgomery';
 
$from = 'US/British dual citizen living in Germany';
 
$blog = 'drupal.cocomore.com/blog';
 
$drupal_interests = array('evangelism',
  
'building cool sites', 'coding', 'design', 'UX');
?>

If we are going to revamp or replace the templating engine then I vote for Twig (I know this has already been done to death in an issue queue with mixed feelings).

I really don't think we should be afraid of introducing a non-PHP solution (it's built in PHP I know, but the user-facing syntax is its own).

And Twig is well-known in the PHP space, has a great team working on it, and squares well with our adoption of other Symfony components.

Please! Not sure how to get there, but theming in Drupal needs to be this easy in order for Drupal to gain more traction outside of the enterprise.

Perhaps a part of the solution is better tools. Many times I've used Devel Theme developer and wished I could just "right-click" on a piece of content I wanted to target and get the code necessary to target it correctly. Or perhaps drag and drop it into place as an editable code snippet.

The biggest frustration for me is just not knowing how to reference "things" properly. The seeming inconsitency or perhaps the fact that there is more than three ways to go about referencing the same object with no clear indication of what, if any, is the "best" way.

I love the idea of the use of "tokens" as a visual concpet. I get it. As a designer, I should be concerned with making sure the last name comes after the first name, that it is styled correctly and, arguably, whether or not it is spelled correctly. I really shouldn't have to be concerned with "technical" issues such as database or PHP structures involved with presenting someone's last name on a "page" any more than a developer should know about the golden mean or color theory in order to formulate an optimized SQL statement.

Colorado mountains