[development] Node Rendering Debate

[sime]

Jeff Eaton wrote:

>
> On Jun 21, 2007, at 12:50 PM, David Strauss wrote:
>
>> The only way I'd go for a FAPI-based $node is if we have a really  clean
>> system for modules creating custom controls...
>
>
> I'd like to jump in quickly and note that it's CRITICAL to  
> distinguish between two thing:
>
> 1) FormAPI
> 2) #prefixed arrays storing structured data
>
> The former is *only to be used for forms*. It is a complete workflow  
> model and set of explicit callbacks.
>
> The latter is a *data format with provisions for complex structured  
> information*. It is something we can use to capture and represent  
> lots of stuff, and solve lots of problems very cleanly. One of the  
> primary benefits of this format is that it can be altered via hooks  
> VERY easily, it can capture hierarchies very cleanly, and it can be  
> rendered in bits using drupal_render() and our theming system very  
> easily.
>
> node_load() can build the node itself in a #prefixed array structure  
> to solve the problem of namespace collisions, and never touch FAPI.  
> node_view() can build a #prefixed array structure in order to  
> leverage the rendering and altering functions, but never touch FAPI.
>
> There are also 'middle ground' solutions -- node_load() could build a  
> #prefixed structure that can be passed to drupal_render() directly,  
> and node_load() could be responsible for adding to and altering that  
> structure in different display contexts. This approach has a lot of  
> potential upsides; flagging specific fields as 'indexable' is one  
> example.
>
> --Jeff
>
>
If the drupal_render on a node is made possible, would you be able 
insert, say, a form somewhere in the tree and have it render? Would you 
be able to nest additional nodes in the tree? Would you be able to 
insert parts of the node under a fapi fieldset elements? Bear in mind, 
I'm not thinking about the ramifications on theming, more I'm interested 
in where we see drupal_render going.