[development] Node Rendering Debate

[Jeff Eaton]

On Jul 5, 2007, at 11:19 AM, Earl Miles wrote:

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

My concern is that any given design will become a combination of  
database configuration information AND a custom tpl.php file. Any non- 
trivial design changes would require admin configuration changes,  
then edits to the tpl.php file, with great care taken to keep custom  
variable names, etc in sync.

I support the idea of passing on a consistent, structured array to  
these tpl.php files by default, and giving designers a simple output 
() style function that prints strings, AND renders/prints drupal  
structures.  output($profile) would print out the whole kit and  
kaboodle. output($profile['personal']) would output just the personal  
information. output($profile['personal'][1]) would print out the  
first item, and so on and so forth.

That gives us the ability to:

1) use variable overrides to pre-render the structure into flattened  
strings if we absolutely don't want themers seeing anything but print().

2) pass on the full structure an allow them to use simple syntax to  
print out various chunks of a node, a profile, etc. without keeping  
additional configuration information in sync

3) give advanced designers the ability to use familiar CSS3 syntax to  
manipulate the structure itself, using fQuery. Rendering all elements  
that match certain critiera, etc. This may be considered 'fluff', but  
it's a way to give designers a much smoother transition from 'simple  
templates' to 'complex' ones without just throwing them into the pit  
and telling them to learn to iterate over nested arrays.

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

I agree. I just think that those named variables should contain  
renderable structures, so that it's easy to drill down and print sub- 
elements without going back to the configuration screen and re- 
tweaking all the 'mappings'.