[development] Code freeze reminder

[Earl Miles]

Frando (Franz Heinzmann) wrote:
> 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.

My primary issue with this is this:

How do I know the name 'links/readmore' or 'comments'? Ok, so core has a few 
variables and they're documented.

Now fivestar comes along and adds 'fivestar_voting_widget'. I have to search 
the module's documentation to find that?

This is the real problem I'm trying to address here. Modules name this stuff 
and it's very difficult to find. This is especially true of FAPI which has lots 
of little widgets and gears and each form names things differently and figuring 
out what you want to tweak is simply difficult.

Also, you have to worry about module naming collusions, which means you end up 
with extra long names. And calling functions in a .tpl.php is supposed to be 
something we discourage, not encourage.