On Nov 16, 2007 11:17 AM, Josh Rosenbaum <[EMAIL PROTECTED]> wrote: > Sounds like an interesting idea. However, I'm not too keen on giving a TT > builder access to perl functions. Using standard TT filters would be ok.
Here are some issues to consider... as I have described the GETFILTER directive it is a compile-time feature. It is also possible to implement it as a run-time feature. In that case the getfilter stack would exist at run-time and could contain code-refs or symbol table pointers. As a compile-time feature the filter function must be resolvable at template compile time. In my situation I prefer to use GETFILTER as a compile-time feature since it gets the job done for me and I don't want to pay the extra overhead to use it as a run-time feature. More dynamic behavior is possible, however, when it is implemented as a run-time feature. The good news is that both implementations of GETFILTER can easily be supported. The grammar can be tweaked so it can used in either case, and by supplying a different factory class one can select between the compile-time and the run-time varieties. The real question is how to expose all this capability to the TT user. _______________________________________________ templates mailing list [email protected] http://mail.template-toolkit.org/mailman/listinfo/templates
