[development] Code freeze reminder

[Earl Miles]

Derek Wright wrote:
>>   5. The node render patch that Eaton started work on a while ago.  I 
>> don't think that is been committed yet, but Eaton recently reminded me 
>> about how important this is to further unify and clean-up the CCK and 
>> core.
> 
> Eaton and I spoke about this at length last week.  We decided the next 
> step for both node rendering and killing the evil $node namespace bugs I 
> was ranting about earlier is to convert $node from an object into a 
> #FAPI-style array.  This is a huge undertaking, but will solve a *bunch* 
> of issues and open up tons of new possibilities.  I've been so busy with 
> update_status that I haven't had a chance to work on the initial patch 
> for this.  If anyone else wants to get the ball rolling, that'd be great:
> http://drupal.org/node/148420

After giving this some long thought, I think I'm basically against this idea. 
The FAPI-style array will give more accessibility to developers, but designers 
don't get FAPI and I fear that it's the wrong direction.

I sent Eaton a proposal that he's not yet responded to (bad Eaton) but that I 
think works particularly well:

The short version of the proposal goes like this:

We create a hook (maybe hook_node_render($node_type)) that creates a list of 
theme functions that will be used to get output for the node. This is all 
inclusive and should get comments, taxonomy terms, pretty much anything that'll 
be attached to a node.

We render this stuff in template_preprocess_node(). We use 
variable_set/variable_get to determine what variable in the array to put it in. 
We default this to 'content' -- meaning stuff that isn't set just gets appended 
to $content. This means our hook, above, does have to do a little work with 
weights. We provide sensible defaults for things like $terms, $links, and other 
node bits that are already separated out.

We expose a UI to let the administrator modify what variable these items are 
placed in. This gives complete visibility to the designer layer. It also means 
we have completely perfect defaults. Themers don't have to mess with 
drupal_render() (which is a really difficult function to work with at the theme 
layer) and it becomes very easy to see everything that can go into a node. 
Moving it around is cake.

I know Jeff has visions of something more complex that can do nesting, but I'm 
really very concerned about the complexity and opacity that this provides. Ask 
any non-developer themer what it's like to work with FAPI. Is this *really* the 
model we want to follow for node rendering?