Tony,
I would argue that the "where it is defined" is almost meaningless, but then
again, I don't know how the template parser works and have never written a
compiler !!
Let's take your example a little further:
------------------------------------
>> [% IF bar %]
>> [% SET foo = 'baz' %] <-- this one's ambiguous -- impossible to know
>> [% END %]
>>
>> [% foo %]
In this case, I KNOW the template engine is going to want the variables
"bar" and "foo". If they get overridden later (by the act of me KNOWING and
setting bar == TRUE), so be it. I just want the chance of setting them to
values. I was guessing that the first pass of the parser/interpreter just
had to hash up the tokens.
>> [% INCLUDE block bar = 2 %] <-- this one's not impossible, just tricky
>>
>> [% BLOCK block %]
>> [% bar %]
>> [% foo %]
>> [% END %]
Once again, in this case the only variables that WILL be substituted are
"bar" and "foo". The interpreter MUST know this before doing any of the
logic.
Then again, if it just evaluates token as it encounters them, you're
probably right, There would be no way to know. I did read however that the
Template::Context() object can "test compile" any template to do syntax
checking by merely:
my($context) = Template::Context->new();
eval{ $context->template("foo.ttl"); };
So I got the impression that any template is reduced to something BEFORE it
is actually processed and the substitutions took place. In my head, this
would mean that the Context object KNOWS the tokens that it will need later.
Am I just making this TOO hard ???? I'm just trying to protect my developers
from themselves. So I am writing a framework for them to use, that they can
give me a template file name and the framework does the rest
($tt->process($filename, \%vars)). It is figuring out the %vars from the
template itself that is at issue.
Thanks
Andy
