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

From: Date: Thu, 06 Mar 2003 22:04:52 +0000
Subject: Re: [SMARTY-DEV] Re: [SMARTY] modifier_string_format in 2.5.0-RC1
References: 1 2 3 4 5 6 7 8 9 10  Groups: php.smarty.dev php.smarty.general 
Request: Send a blank email to php-smarty-dev+get-903@lists.php.net to get a copy of this message
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

« previous php.smarty.dev (#903) next »