Re: Template Question [last!!]

Wim Niemans ri wrote:
>>>This cumulating is exactly what is intended.
>>
>>Ah. It was precisely what we wanted to avoid :p
> 
> Well, that's the architectural constraint. Is there any raison for wanting 
> to avoid that?

If Nodes are seen as modules, 'black boxes', they should provide 
autonomous output and be independant from other nodes.

>>Sorry, but I think there's a big misundestanding here then :/
>>All you tell here is possible with current design. I'd recommand you to 
>>use css for themes rather than moving page blocks.
> 
> Yes, yes. Agree. But still designers should be allowed to modufy the page 
> as a whole. I see a marketing issue in this.

Other alternatives I can think of are
* to move the {$children.my_child_id1} in the top node tpl
* if you don't need logic in your children, simply use tpls included 
from the top one and pass them vars {include file="childtpl" 
value1=$value12}

> Not necessarily javascript. Could be css as well. The issue is to have a 
> complete page in one go, and enable fiddling around with it. 

If it's repetitive data, i see it as a table.
Should not be a child per invoice in the list.

>>I'm happy if you use bc, I'll be even more if you contribute to ehance 
>>it 
> 
> What struc me about bc is the statement that 'the code is beautifull'.
> I agree on that. The more beauty in the code, the more thoufhtfull it is 
> designed, the better is it. Well, I'm planning to port a portal to bc, and 
> my logistics aplications.
> 
> Thanks again for your support. It's a great help.



> btw. to get some opinions on the portal-port, is that a good idea to post 
> to the list, or is a draft better suited?

If it's long, write a draft on the wiki, then point us to it.

--

-- 
Jean-Christophe Michel