[development] Node Rendering Debate

[Darrel O'Pry]

On Wed, 2007-07-04 at 22:12 -0700, Earl Miles wrote:
> Darrel O'Pry wrote:
> > 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'... 
> 
> What's interesting is that in my vision, CCK's UI basically goes away, replaced 
> by a more global one. CCK just ends up adding stuff to that UI.
> 
> And I still have my doubts that the drupal_render() stuff will be transparent 
> enough for themers to use. I worry, very strongly, that this path is going to 
> make it so that only developers can theme nodes.

I totally agree with your view point on CCK's display fields tab, and
the field_group module. They're only remedial examples of what is
possibly and should have a scope much wider than CCK. 

I just feel that you approach tends to cater to designers that think of
design in a page by page manner, instead of a collection of widgets with
many potential layouts. Then again I may be completely mis-understanding
your idea, after all you did do that panels thang :).

There are also technical merits to drupal_render that I wouldn't want to
see lost... the most important one for me is the potential for caching 
Creating a central pipe line for the processing means we have a single
point of focus for caching based optimizations and process improvements.

Personally, I'd like to see it become capable of caching branches in the
render array tree in various states including built abstraction, altered
abstraction, processed abstraction, rendered abstraction. It at least
seems like it would be fun to experiment with.

Since the DataAPI and FormAPI extend the model, they too would probably
benefit over time as we gain more expertise with it.