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