On Wed, 2007-07-04 at 08:05 -0700, Farsheed wrote:
Ugh! is it really that hard to print_r($node) in your theme during development when you're looking for a var?
I personally think the print_r(object structure) is much easier to deal with than having to get_defined_vars, which is normally a big interesting mess.
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.
A UI could help the themer have access to more data from other parts of Drupal and format it the way they want.
I think saying that print_r solves the problem is oversimplifying the issue. We should think about this some more.
The issue is node rendering with drupal_render or and additional api for node data to be renamed to specific variable names for themes. I think print_r is a perfectly acceptable solution, you can look at the variables hook in your template.php. this isn't to be confused with more general issue about getting more data into the theme layer from nodes, or how do access data that isn't exposed to the theme layer, dynamic layouts, etc. Much of which the renderingAPI can accomplish. There are some really cool things in CCK such as field groups that provide a basic demonstration of how the layout can be manipulated through a UI, and CCK's handlers which can be translated to the renderAPI via the #theme or as a custom element type. Rendering more content using drupal_render give us more access to manipulate the output through _alter and #whatever callbacks we choose to create in the rendering pipeline. The problem with drupal_render currently is we're limiting it to generating node bodies. This is a highly nestable API... I'm not sure why we aren't rendering pages using this as a starting point and having new renderAPI element type like 'page', 'section', 'block', 'container', 'node'... I know we all probably think of this as FormAPI at the moment, but formAPI is the renderAPI with some form processing specifics built on top of it. FormAPI is a misnomer, and some people quip about it being the everything api. The really awesome part of formAPI that makes it so flexible is the rendering API it is built on top of. The nested processing with override-able callbacks, and the build abstraction / inspect abstraction / process abstraction / render abstraction processing phases. This makes the core of it highly adaptable and extensible. DataAPI will be build on top of the same general process I assume. I'm not sure if I have the proper diction to describe what I'm calling the renderAPI, if you have better words or better explanations I'd love to learn them. I need to see something really elegant and usable to convince me that there is any reason to focus my energy on building a new platform for abstraction, instead of maturing the ones we have.