allow template-inheritance to declare variables, macro's and import/include

[mpo]

(see discussion @ ​http://groups.google.com/group/kauri-discuss/browse_thread/thread/61cd09766f0ea91b#)

Currently, when inheriting from a template only <t:block> elements are considered and executed.
In these blocks there is no way to refer to:

• common variables
• common macro's

that would be either in the derived template itself, or imported/included from somewhere else.
This is quite limiting.

Maybe we could consider introduce a special block:

<t:extends></t:extends>

that

1. doesn't generate any output, and only allows for variables and macro's to be

defined, plus evaluate variables/macro's from imported/included templates.
Note: the scope of these should not be tied to this block, but instead made available on the template level.

1. should be able to occur anywhere in the file, and thus should be pulled up automatically. Ideally more then one such block could occur, all of them being executed after each other. (although a first iteration requiring it to be upfront in the file seems acceptable)
2. executes as if the base-template was injected at the top with the (stripped) t:extend blocks of the deriving template

So executing the special.xml below should be equivalent to executing flat.xml

base.xml
<root>
  <a><t:block name="a"></a>
  <b><t:block name="b"></b>
</root>

util.xml
<t:if test="true">
  <p>output which will be ignored</p>
  <t:variable name="x" value="ieks"/>
  <t:macro name="m" >
    <t:parameter name="p" value="pee"/>
    ${p} en ${x}
  </t:macro>
</t:if>

special.xml
<ignored t:inherits="base.xml">
  <t:extends>
    <p>more output that will be ignored</p>
    <t:include src="util.xml" />
    <t:variable name="y" value="ei"/>
  </t:extends>
  <t:block name="a">aa en ${x}</t:block>
  <t:block name="b">
    bee en 
    <t:callMacro name="m"><t:parameter name="p" value="${y}"></t:callMacro>
  </t:block>
</ignored>

flat.xml
<root>

  <t:variable name="x" value="ieks"/>
  <t:macro name="m" >
    <t:parameter name="p" value="pee"/>
    ${p} en ${x}
  </t:macro>

  <t:variable name="y" value="ei"/>

  <a>aa en ${x}</a>
  <b>    
    bee en 
    <t:callMacro name="m"><t:parameter name="p" value="${y}"></t:callMacro>
  </b>
</root>

This probably calls for a special include/import mode during template compilation that allows to supress/ignore the output statements. If it would explicitly exist the flat.xml would read:

flat-with-mode.xml
<root>

  <t:include src="util.xml" mode="silent" />
  <t:variable name="y" value="ei"/>

  <a>aa en ${x}</a>
  <b>    
    bee en 
    <t:callMacro name="m"><t:parameter name="p" value="${y}"></t:callMacro>
  </b>
</root>

This silencing should taint (automatically proceed over to) any further import/include happening from util.xml or the <t:extend> block

[bruno]

I just started playing with template inheritance in tupper, and quickly ran into a situation where I need this too (the case: load contact data into variable, show parts of it in different blocks).

As a workaround, you can create a block in which you only define variables and macros, and call that block in the base template.

It seems like the variables defined in that block are also visible to other blocks, which is quite handy right now, but that is probably an error.

[jgou]

The requirement "executes as if the base-template was injected at the top with the (stripped) t:extend blocks of the deriving template" was a bit in conflict with the use of global variables in the base template itself: should variable x from an extend block in a child override a global variable x in the base template ? In the use case from ​http://groups.google.be/group/kauri-developers/browse_thread/thread/d8e59d094a1266a1?hl=nl# that seems to be the expected behaviour. But I can imagine this will not always be the case. Since the base-template author can decide which parts can be overwritten in child templates, and which not, it might be better to do more or less the same with the global variables. By placing them in a 'extend' block, they can be overridden, by placing them simply as global variables they keep their 'base' value. This ensures that there are no possibly confusing side-effects in the not-to-be-overwritten parts, where otherwise a change could be invoked by manipulating a global variable.

In this proposal, the 't:extend' block acts somehow similar to a java constructor, and certainly when using it on the base template, the name seems a bit odd. Therefore the suggestion is to use t:init instead. I went ahead and renamed it already (but this can easily be undone).

[jgou]

work on t:extend started in [822] and [836]

renamed to t:init in [841]

compatible with t:import/t:include (see #149) since [909]