[% INCLUDE foo/bar/ping %]
or
[% INCLUDE foo/bar/pong %]
If the template specified (e.g. foo/bar/ping) can't be found then it
backs up the path until it can find a template (e.g. foo/bar) which
defines the block identified by the remainder of the path (e.g. ping).
This feature is disabled by default, but can be enabled by setting the
EXPOSE_BLOCKS option to any true value.
For completeness, I've also made a change to the parser grammar which
allows you to define BLOCKs nested within other BLOCKs.
[% BLOCK document %]
[% BLOCK header %]
This is the header
[% END %]
[% BLOCK footer %]
This is the footer
[% END %]
[% END %]
You can then access these blocks from the same document as, for example:
[% INCLUDE document/header %]
or from an external document like so:
[% INCLUDE foo/bar/document/header %]
It was previously possible (but never documented or recommended) for
you to define nested blocks, but their names wouldn't be modified to
indicate their nesting (e.g. the blocks in the above example would be
called 'document', 'header' and 'footer' rather than 'document',
'document/header' and 'document/footer'). If anyone was previously
expecting any well-defined behaviour from this kind of nested BLOCK
definition, then they shouldn't have been :-)
So, feeling confident that I'm not going to break anything (all tests
continue to pass, including some new ones I added to test this feature)
I'm about to commit the changes to the CVS repository ready for the
next developer release, 2.07c. There's also a couple of tweaks I need
to apply to the constant folding code recently added, so 2.08 is on hold
for another few days at least.
Unless I hear any objects, of course....
By the way, credit is due to Doru Petrescu who sent me a patch (ages ago)
offering something similar to the loading-blocks-from-external-templates
change mentioned above. I chose a slightly different style and implementation
in the end, but he got me started on thinking about it. Thanks Doru!
A
