[development] Node Rendering Debate

[Darrel O'Pry]

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.