[development] Node Rendering Debate

[Earl Miles]

Darrel O'Pry wrote:
>> And I still have my doubts that the drupal_render() stuff will be transparent 
>> enough for themers to use. I worry, very strongly, that this path is going to 
>> make it so that only developers can theme nodes.
> 
> I totally agree with your view point on CCK's display fields tab, and
> the field_group module. They're only remedial examples of what is
> possibly and should have a scope much wider than CCK. 
>
> I just feel that you approach tends to cater to designers that think of
> design in a page by page manner, instead of a collection of widgets with
> many potential layouts. Then again I may be completely mis-understanding
> your idea, after all you did do that panels thang :).

That's interesting. I'm not sure how that really follows, though; but since 
thinking about it this way may help, I think of the UI as CCK's 
field-ordering/grouping UI except with *Everything* in it, not just CCK fields.

I don't immediately see how that caters to not having many potential layouts; 
the easieast way to do that is to put everything into named variables and then 
do those potential layouts.

> There are also technical merits to drupal_render that I wouldn't want to
> see lost... the most important one for me is the potential for caching 
> Creating a central pipe line for the processing means we have a single
> point of focus for caching based optimizations and process improvements.

I'm not sure they'd be lost; I think they'd be moved up to happening much 
earlier in the process, perhaps. Then again, perhaps they would be, since their 
internal name mapping would disappear (as it becomes unnecessary).

> Personally, I'd like to see it become capable of caching branches in the
> render array tree in various states including built abstraction, altered
> abstraction, processed abstraction, rendered abstraction. It at least
> seems like it would be fun to experiment with.

Repeat that sentence to a designer. =)