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.

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.

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

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

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.

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

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.

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

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

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.

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.

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.

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:

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!

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?