Alternately, we can simply instruct people to build their presentation data drupal_render()able structures, then pass them on to the theming layer, where the are collapsed into strings or exposed as complex structures depending on the application. Drupal has too many nooks and crannies were the same data is stored and accessed in completely, counter-intuitively different ways. Layering another vocabulary, another set of mapped variables, another slice of metaphor and abastraction, on top of the current models is not IMO a solution. That's one of the reasons that I think any real solution will overlap with the node object's internal structure, our APIs for outputting different formats (JSON, XML, HTML, etc) as well as our rendering and theming systems. Our goal must be to make the system more consistent and flexible, to eliminate special cases and edge-case exceptions. --Jeff On Jul 4, 2007, at 10:05 AM, Farsheed wrote:
Print_r is a fine way to see what variables are *available*. How to assign or create new variables and make that data available to the theme is an entirely separate and more complicated issue. And that involves knowing what is literally available from drupal to assign. It often leads to having to code dive into someone elses module to figure out how to get the information you need to print out.