Re: [SMARTY-DEV] compilerblock plugins patch

I'm wondering, what if we changed the block functions to use this method, does anything break? (besides needing to be recompiled) If not, this would keep the API simpler and no new documentation needed, maybe a technical note adjustment. Does your method resolve the issue of evaluating variables in a block function at runtime? Problem outlined in this posting: http://marc.theaimsgroup.com/?l=smarty-dev&m=103774868829224&w=2 Monte On Mon, 2002-12-02 at 05:47, M Mohr wrote: > hello, > > i patched smarty to support block-function at compile time. the > compilerblock-function is searched as compilerblock.[name].php in the > plugins_dirs and has precedence before simple (==old) > compiler-funcions. > > alternatively you can register compilerblock-functions using > $smarty->register_compilerblock_function(..). > > the function has to be declared as: > > function func($tag_args, $start_tag, &$smarty) ... > > or > > function smarty_compilerblock_csv($tag_args, $start_tag, &$smarty) ... > > where tag_args ar the (unparsed) arguments, like in the simple > compiler-functions and $start_tag is a boolean indicating wether the > function was called at the beginning or the end of the block. > > i attached the diff against the lates cvs-version. it's not small, but > pretty simple, since it is a mainly a rip-off of > Smarty_Compiler::_compile_block_tag() > > i would love to see it applied in Smarty-2.3.2 and i am willing to > provide documentation for such plugins and to maintain this patch if > necessary. > > any use for it? > any comments? > > regards > messju mohr > > ______________________________________________________________________ > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php -- Monte Ohrt <monte@ispi.net>