The drop is always movingYou know that saying about standing on the shoulders of giants? Drupal is standing on a huge pile of midgetsAll content management systems suck, Drupal just happens to suck less.Popular open source software is more secure than unpopular open source software, because insecure software becomes unpopular fast. [That doesn't happen for proprietary software.]Drupal makes sandwiches happen.There is a module for that

The mistake we made in templating

Submitted by nk on Sun, 2011-05-15 09:26

In a long and fierce debate with Jen Lampton (mikey_p, HedgeMage and heyrocker was involved some as well) we have arrived to an incredibly important realization: theming newbies apparently don't find simple logic (if, print, function calls) problematic they have problems with data structures! If you compare the first line of node.tpl.php in Drupal 5

<div id="node-<?php print $node->nid; ?>" class="node<?php if ($sticky) { print ' sticky'; } ?><?php if (!$status) { print ' node-unpublished'; } ?> clear-block">

to most templates in Drupal 7 which are full of print render($page['header']); and the like (and let's not mention that theme calls now mandate the use of arrays) then we have moved the exact opposite direction. We might need to reverse this if this revelation rings true to other members of the community.

Ps. Jen also wrote a post on this.

Ps2. I wrote http://drupal.org/node/1158090 as one possible way to remedy most of the complaints about render().

Commenting on this Story is closed.

Submitted by Anonymous on Sun, 2011-05-15 09:36.

Templates should never carry data structures, it's not being templates anymore. While I'm against business logic in templates, it's still better than having arbitrary hierchical, often undocumented huge rendering arrays in these.

Rendering arrays are basically good because if used well they allow the theme layer being inited only once the full response data is set (no business logic is being computed anymore), which means that if I want somehow to send this data array through JSON, I could without initing the theme at all at delivery time.

But, in the other hand, if the page has to be rendered as HTML, then theme has to be inited, templates should probably be rendered in a top down fashion (children first, such as the form API validation process) in order to ensure that templates will ever only carry 'echo-able' string variables with which all themers are pretty well used to.

Submitted by pounard on Sun, 2011-05-15 09:39.

First comment is mine (wasn't registered).

Submitted by Anonymous on Sun, 2011-05-15 14:13.

"which means that if I want somehow to send this [render array] through JSON, I could without initing the theme at all at delivery time."

Except that this is not the contract you sign by "being a render array". In D7, render arrays are still about producing HTML through the render and theme layers, not about presenting data in a way that makes sense for the outside world. This very point is (one of the aspects) debated in http://drupal.org/node/145551.

yched

Submitted by Anonymous on Sun, 2011-05-15 09:36.

While I'm not convinced that the first line is any more or less complicated than the second, I agree they are both complicated in their own ways. So +1 to any simplifications that can be found there. Removing data structures from theme templates is a worthy goal.

Submitted by pounard on Sun, 2011-05-15 09:41.

The given example wasn't good. It should have been a line that does a

<?php
hide
($node['something']); print render($node['something']);
?>
I guess instead.

Submitted by Anonymous on Sun, 2011-05-15 10:49.

Maybe I am a purist but, when I build my own themes, I limit everything in the template to a simple

<?php
print $foo
?>
and the rest goes into template.php - I don't know if it's a failing of how we're getting to the render as much as it is the actual function call in the tpl.php file. Just my two pennies. -webkenny

Submitted by joates on Sun, 2011-05-15 11:26.

data structures do not belong in templates !!

module developers use complex data structures that describe the data and they understand them, in many ways it makes their job easier.
I think it was Crell that once said "having a really awesome hammer makes *everything* look like a nail!", the drupal_render() function that works so well inside modules with the Form API has found its way into *.tpl.php files now as render() and that has paved the way for arrays and objects to follow it.

themers do not understand complex data structures (like arrays and objects) and should not be expected to, its like an italian going to Moscow and shouting instructions at the Russians, they are just going to ignore it because they don't understand, (for the few Russians that have learned Italian its not a problem - but you must understand that they will certainly be the minority). To communicate effectively with the audience that you wish to share information with you *must* speak in a language that they can understand, we should not be expecting them to learn our language!

I am both developer and (part-time) themer.

Submitted by Anonymous on Sun, 2011-05-15 11:51.

I think we should use a dedicated templating language other than PHP for templates. The language we use for templating shouldn't have any logic or data structures.

jbrown

Submitted by Anonymous on Mon, 2011-05-16 01:37.

This would make things even harder, print or write is good, lets not overcomplicate things by having our own templating language. -ipwa

Submitted by bangpound on Sun, 2011-05-15 12:28.

This is why Semantic Views was created. The Views fields row template was very difficult to understand, and it was the one people often wanted to change. Control structures were one thing... a foreach loop through the $fields array. But then you have the stuff on each field object: a value, a raw value, a label, etc. People get lost. Heck, I am not a newbie and I can't override some templates without debug() and dpm().

It's worth noting that sometimes the "simple" logic and the data structures are tied up together. You can't have a foreach loop without a data structure.

Submitted by Anonymous on Sun, 2011-05-15 13:01.

The reason why we introduced render() and friends is to solve the problem where templates started printing parts $content all over the place such as fields, taxo links, user picture, etc. Once you do that, you don't ever print out $content. And once you do that, your template is hard coded. When you add new module, it won't work! Its content never gets printed.

When asking the community their opinion about a themeing change, let's provide the reason why we do it this way instead of just pointing out the ill effects.

This change is not really about performance. There is a minor benefit that you can not ever render stuff you don't care to show.

-moshe

Submitted by Anonymous on Sun, 2011-05-15 14:04.

"When you add new module" *or new field*, it won't work.

The goal was also to get rid of the major security risks opened by encouraging people to directly print bits of $node->field_foo raw data.

Also, render() and friends emerged and gathered consensus after a lengthy discussion (http://drupal.org/node/455844, for the record), which involved several theme-oriented people. Granted, probably not the typical drupal-beginner themer profile, though.

Submitted by Anonymous on Sun, 2011-05-15 15:13.

I do a lot of theming, and my only complaint is the endif; syntax. I have to work a lot under Windows, and with endif; I just can't get my favourite text editors highlight the corresponding opening/closing marks. First thing I do with a template is get rid of endif; and insert the standard curly brackets.

I also find it somewhat baffling that anyone thought if: endif; is easier than if {}. Anyone with IQ above 80 could handle both. Other than the syntax hightlighting problem, it's a non-issue. But when syntax is different in theme files and elsewhere in Drupal, e.g. in template.php (where "themers" also end up sometimes) now that is confusing.

Other than that, I have no complaints. (I used to, but they were solved in D7 with hook_process(). Thanks for that!).

When people make statements like 'themers can't do this' or 'themers can't understand that', I would like to see some research data to back up those claims. Otherwise we are just talking about assumptions.

Edith

Submitted by Anonymous on Sun, 2011-05-15 19:49.

It's not in templates because it's easier, it's in templates because it allows big swaths of HTML inside conditionals that would otherwise have to be included from somewhere else or print/echo-ed out as a large string. This means indenting and syntax-highlighting of the html can be preserved.

This is obviously less critical when outputting e.g. $scripts, but can be very useful when outputting anything that requires any remotely complex html in templates.

Submitted by Anonymous on Sun, 2011-05-15 18:06.

As someone who can remember being a theming newbie I never found data structures confusing. Rather I always found having hard coded html in templates confusing. Data structures are what most other web frameworks that I'm familiar with use. Data structures make sense because they mean that someone who is familiar with html only has to really worry about html (not things like template_preprocess functions).

I agree, however, that the Drupal 7 syntax for printing out these data structures is rather verbose and intimating looking. As such http://drupal.org/node/1158090 looks like an improvement.

Submitted by Anonymous on Sun, 2011-05-15 19:42.

Like the commenter above, while data structures can be confusing, more frustrating as an entry-level themer is the amount of HTML Drupal outputs in some of these variables and the difficult process of changing/removing this markup.

I would prefer a focus on this aspect of theming. Also, slightly off-topic, but removing CSS from core too would be nice!

Submitted by Anonymous on Thu, 2011-05-19 21:09.

YES! All the tags sucks. I'd rather have much, much less markup in core (and contrib) for that matter.

Submitted by Anonymous on Mon, 2011-05-16 09:53.

It's not just the noobs. I also find data structures tricky. But it boils down to having to learn some new syntax. What we really need right now are some nice blog posts or documentation examples walking through exactly what to do.

I don't think there is anything all that complicated about the data structures themselves – array, keyed array, multidimensional array, all easy to understand – it's getting the information out of them that I find tricky.

Submitted by Anonymous on Mon, 2011-05-16 12:32.

I do not agree with having data structures or function calls in templates. Templates, in my opinion, should only contain markup, and in some cases, if statements. I hate the fact that everything is wrapped in render() function calls in the templates.

Submitted by Anonymous on Mon, 2011-05-16 14:55.

My main problem with templates in D6 -- as a coder who's done plenty of theming as well -- is that in plenty of files, you don't really know what variables you got at your disposal. Sure, the default templates tend to have it in comments at the start, but it doesn't mean I know exactly what to expect.

In that aspect, data structures are very useful. It's like: "Yeah, I want a cookie. The cookies are in the kitchen, in the cupboard, on the top shelf on the left" so you go into the kitchen, into the cupboard, look on the top shelf, on the left and there you have your cookie! It's better than saying: "I want a cookie. Let's see if one exists. Oh, it doesn't exist... How do I get a cookie now?"

The problem with this, though, is that it requires a bit more initial investment into getting to know the data structure. That means the learning curve increases a bit. It's not that big a deal, if properly explained, though. In the past months, I've had to teach a designer how to use Drupal. The moment he understood how Krumo works, he gained ALOT of autonomy! A function look_inside() or such for themers would thus help.

That said, for very, very, very simple templates, loose variables can be more useful, too. I mean, it's just easier to say:

<h1>Hello, <?php print $name; ?></h1>
<p>Today is <?php print $date; ?>. Here is your daily message:</p>
<?php print $message; ?>

For something as simple as that, a data structure'd make things more complicated than necessary. Building a theming engine based solely on such simple examples, though, ensures a huge lack of flexibility. So, having the two options should be good (perhaps through a hook in template.php, where you can define loose variables based on the data structure, like $args['name'] = $data['user']['name']), along with simple function names that make sense to non-programmers (even to me, as a programmer, I still don't know what "krumo" actually means!) All that together should do the trick.

...

And daaaayum, that's one big comment I just wrote!

Submitted by Anonymous on Tue, 2011-05-17 00:22.

I think Drupal is the only PHP template system out there that requires people to know the difference between an array and an object. And given that even PHP can't really figure out which is which, how are the designers supposed to know?