Re: BTemplate is not fully compatible with XMLC philosophy

Hi,

I've been stumbling over this too, in my early days :)

> When executing this code the text inside the <p> element with id "xmlc"
> will not get replaced! Please don't ask why I want to dhttp://
www.megatokyo.com/o this, just take it
> for granted.
> It seems that the BTemplate component clones the node to which it is bound
> to and then replaces the "old" node (I'm not sure but I think so). Setting

Your thinking is correct.

> the text inside the <p> element before rendering the BTemplate will work.
> But I don't want to be limited to do DOM manipulations via XMLC at first!
> Another problem arises if you call "page.getElementXmlc()" after rendering
> of BTemplate because you will get the "old" node which doesn't reflect the
> new document.
> If I'm right, please, please, please change the the way BTemplate renders
> itself to not cloning the node.

Its not possible, or at least not easily. The cloning is neccessary - the 
subtree is used as template. Because BTemplate allows iterative directives, 
you can't just modify the existing tree. What would you expect to happen when 
the id-marked node of your example was inside an iteration, and thus is now 
manyfold? 

There are two possible solutions for your problem - either you create a finer 
granulated template, where the BTemplate controls only parts it can control, 
or you let the value that is now xmlc-controlled also be rendered by 
BTemplate.

From my expirience, I can say that we only work with BTemplates - several per 
page (see my pages example), but all dynamic content is only filled in using 
BTemplate.

I know that some people say that this approach loses the xmlc-compiletime 
capabilities, but the web _is_ an utterly text-based and late-bound beast....


However - if you want to try to deal with it, you can of course. But the 
template mechanism is one of the most complicated parts of Barracuda, and the 
grasp I had of it when actually patching is has drained long ago, so you're 
on your own there (unless other commiters stand up, of course).

Regards,

Diez