Re: [SMARTY-DEV] Re: [SMARTY] modifier_string_format in 2.5.0-RC1

On Thu, Mar 06, 2003 at 04:24:35PM -0600, Monte Ohrt wrote: > On Thu, 2003-03-06 at 16:21, messju mohr wrote: > > On Thu, Mar 06, 2003 at 04:12:33PM -0600, Monte Ohrt wrote: > > > func_get_args() was not available when Smarty was first written. Also, > > > args cannot be passed by reference this way. > > > > hmm, i never needed to pass args by reference to a modifier AFAIR. > > You just said you'd like the &$smarty object available :-) But Paul > makes a good point, the $smarty object isn't too useful in a modifier. <not seriously> hmm, i could try: $smarty->assign_by_ref('smarty', $smarty); function smarty_modifier_foo($string, &$smarty) { $params = func_get_args(); $params = array_slice($params, 2); // use $smarty->... for nasty things here // use $params[] for other stuff } and call my modifier {$var|foo,$smarty,...} but some guys in my office would come with a big baseball-bat after me if i tried that ... ... and i guess i would even deserve it :) <seriously> have fun messju > > > > and func_get_args() is available in every version of php that supports > > a reasonable up-to-date version of smarty. > > > > > On Thu, 2003-03-06 at 16:04, messju mohr wrote: > > > > On Thu, Mar 06, 2003 at 03:55:47PM -0600, Monte Ohrt wrote: > > > > > Hmm, I'm not the originating author of the modifier structure, but > > > > > I'll > > > > > take a guess :-) Function attributes have name/value pairs so an > > > > > associative array makes sense, and order is not an issue. OTOH, modifier > > > > > parameters are only values so their order is important. I suppose they > > > > > could have been passed as an enumerated array of values, that way the > > > > > second parameter can be the smarty object much the same as functions > > > > > are. But then your modifier would need to know what each value of > > > > > $params[0], $params[1], etc. are for without an intuitive name. > > > > > > > > one can use func_get_args() to write modifiers with a variable number > > > > arguments, so there is no need to break bc for this. > > > > > > > > but having &$smarty available in modifiers would be worth it for me... :) > > > > > > > > > > > > > > > > > Monte > > > > > > > > > > > > > > > > Ok, I see the difference and how it works now, though I can't say > > > > > > that > > > > > > it is the most intuitive implementation. Usually the modifier modifies > > > > > > > > > > > > the string it is attached to, not the other way around. For people > > > > > > like > > > > > > myself who want it the other way, and for the sake of backwards > > > > > > compatibility, one can simply register the modifier in the code as I > > > > > > have done. > > > > > > > > > > > > As an idea for being able to attach what is basically a dynamic amount > > > > > > > > > > > > of arguments to a modifier, why don't you make modifiers work the > > > > > > way > > > > > > function plugins do: pass a $params variable that is an array of all > > > > > > the > > > > > > arguments? That seems to be somewhat logical and at the same time > > > > > > backwards compatible with existing templates, even though all modifier > > > > > > > > > > > > plugins will have to be rewritten. > > > > > > > > > > > > ~Paul > -- > Monte Ohrt <monte@ispi.net> -- Torx-Schrauben: Hände-Weg-Schrauben nach Marc Habers Kollegen