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. =)