Hi,

 

Not sure anyone here has heard either of Bassett's Frames or the XML
recasting of them as XVCL. Anyway, XVCL is a very nice templating formalism
which is unfortunately trapped inside of XML syntax and implemented in Java.
XVCL's primary feature which I want to implement in TT is that of a <break>.
A <break> is a named slot which gets defined in the body of a template. When
the invoking template INCLUDE's that template, the invoker has the option of
providing an <insert> with the same name as the slot in the template. In
case no such <insert> is provided, the template can have a default value for
that <break>. So, an <insert> is much like an actual parameter to the
template function's formal parameter (i.e., the named <break>).

 

Now, the [% WRAPPER %] request is quite like a degenerate form of the
<break>/<insert> which only provides for one such unnamed template block. I
need to have any number of these <break>s in my templates. My understanding,
however, is that the [% WRAPPER %] block provided will get expanded in the
context of the the other template which [% GET %]s the content of the [%
WRAPPER %] block.

 

Now, in terms of implementing the mechanics of this, it occurs to me that
the <insert>s are very much like templates which should get compiled, with a
reference being passed to the context of the invoked template. So, instead
of having a <break> in the body of my invoked template, I would like to have
an [% INCLUDE %] template directive, which some has the ability to invoke
the resulting perl subroutine which is the compiled version of the <insert>
block.

 

I know that I can define a [% BLOCK %] and even give it a name. The problem
is that a [% BLOCK %] is only visible withing the file it appears and since
any number of templates might want to [% INCLUDE %] the other template which
has the <break>, if I were to bind that [% BLOCK %] to an external file, I'd
need to have two or more of them all with the same name. The other problem
is that each of these <insert> blocks need to be bound to a name which is
only known by the template which has the corresponding <break>. While I can
easily bind a name to a [% BLOCK %], I have no way to make that static name
known to the other template. Also, if template B is [% INCLUDE %]ed into
template A at points A1 and A2, then I would need to bind A1's <insert>
block and A2's <insert> block to the same name, so that template B would be
able to refer to either consistently. This, of course, would be solved by A1
and A2 passing a reference to the block.

 

The obvious solution would seem to be to have some way to invoke a template
[% BLOCK %] or template file by reference as in Perl. I know that it is
possible to assign a [% BLOCK %] into a variable, which actually assigns the
expanded [% BLOCK %]. Is there some way to get a handle to my block, which I
could then pass to another template, which could take that handle and then
expand the actual [% BLOCK %] using that handle and the current context?

 

Another way of looking at the <break>/<insert> mechanism is to view it as a
callback. Inside of my template, I could implement a <break>, by using [%
INCLUDE %], but instead of providing a name or filepath to the template, I
would need to provide the handle/reference to the compiled <insert>, which
is a compiled [% BLOCK %].

 

I do see one option for implementing this, which is to take advantage of
dynamically compiling the <insert> [% BLOCK %] by doing the following:

1) capture the text of the template into a string variable without compiling
the template at the point where the <insert> is defined

2) pass that <insert> template text to the other template

3) in the other template, I compile the <insert>'s text using the EVAL
Filter

 

The only reason I don't like this is that I see no reason why I shouldn't be
able to precompile the <insert> along with all of the other templates and [%
BLOCK %]s.

 

So, is there some simple hack I can use to get a reference to the compiled
perl subroutine for a [% BLOCK %] and correspondingly use that reference to
[% INCLUDE %] that compiled template into another template? Alternatively,
could anyone suggest an alternative way to get what I'm trying to get? If my
descriptions are not clear, I'd be pleased to try again, given feedback.

 

Thanks,

Glen

 

 

 

_______________________________________________
templates mailing list
[email protected]
http://mail.template-toolkit.org/mailman/listinfo/templates

Reply via email to