Paul Seamons wrote:
[SNIP]
[% GET foo %]
[% CONFIG
ANYCASE => 1
PRE_CHOMP => '-'
POST_CHOMP => '~'
TAGS => 'html'
INTERPOLATE => 1,
%]
[SNIP]
The following would be some samples of runtime options - I
think that they would have to be enabled with a new flag along
the lines of ALLOW_RUNTIME_CONFIG => 1 (default 0) - otherwise
the directive should die:
[% CONFIG
INCLUDE_PATH => ['/home/user/templates']
EVAL_PERL => 1,
%]
If that is the case then, it would then be nice to drop priveledges
also:
[% CONFIG
ALLOW_RUNTIME_CONFIG => 0
%]
I think that once it was turned off - it couldn't be turned back
on - or better yet - run time options should be lexical - so that
if you call PROCESS - they are permanent - but if you call INCLUDE
then the options would only be in effect during the include.
It would also be nice to be able to query the options - but this would
probably be best done through the "template" variable.
[% can_perl = template.config('EVAL_PERL') %]
[% current_path = template.config('INCLUDE_PATH') %]
The INCLUDE_PATH variables should probably not be available unless
the ALLOW_RUNTIME_CONFIG variable is set.
[SNIP]
Any other ideas?
You must be itching to do some development. ;)
Well I like these ideas, but I think there needs to be a global hash that we can
modify to tweak the access to these config options as well as to set a default of
whether they can be modified or not. In particular EVAL_PERL and INCLUDE_PATH should
NOT be allowed to be modified by default. Or instead of a global hash, we could pass
a hash via the ALLOW_RUNTIME_CONFIG key to specify what should be allowed and what
shouldn't. (Of course the hash should not be allowed to be passed in via tag call.
ie: [% CONFIG ALLOW_RUNTIME_CONFIG => {this_is_bad => 1} %]
-- Josh
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates