[development] Code freeze reminder

[Frando (Franz Heinzmann)]

Earl Miles schrieb:
> 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?
> 

Hm - what about sticking to the FAPI-model (as it provides really a 
great level of flexibility, and consistency), and providing some really 
easy helper functions for designers?
This came up in the node rendering thread.

That would mean that we'd just pass a #fapi-style structured array into 
node.tpl.php.

There, as a designer, in node.tpl.php, you could do things like:
hide('links/readmore', $node);
hide('comments', $node);

And do show('attachments', $node) at the exact place where you want to 
display the (rendered) attachments.

At the end of node.tpl.php, you'd then just put render($node) or 
something, which drupal_renders everything that is not hidden by hide() 
and not yet shown by show().

Under the hood, show('links/readmore', $node) would return 
drupal_render($node['links']['readmore']) and set 
$node['links']['readmore']['#rendered'] to true. hide() just sets 
#rendered to true for the element, which should then cause it to not be 
displayed by the final render() call (which is just a wrapper for 
drupal_render). They would of course all operate on $node by reference.

This sounds like a solution that gives us lots of flexibilty for the 
developer's side, yet keeping this simple for designers.

regards,
frando