Re: [SMARTY-DEV] Re: object support

The only downside I see of a custom function is (aside from tedious syntax), you don't have the ability to use an object method directly as a parameter: {myfunc var=$foo->bar("blah")} instead you have to do a couple steps: {object name="foo->bar" p1="blah" assign="myobj"} {myfunc var=$myobj} On Fri, 2003-01-10 at 10:09, André Rabold wrote: > NO! :-) Just a joke, sure it's acceptible. ;) > > Thanks, > André > > > "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag > news:1042213003.12485.15.camel@lena.ispi.prv... > > If we provide a way to enable, we have to support it and document it, > > which leads to more syntax support. I left the more complete object > > regex commented out in the code. > > > > I'm kind of up in arms about the whole object support. It is nice, yet > > it potentially opens a can of worms. > > > > Currently, Smarty supports access to object properties: > > > > {$smarty->foo} > > > > but not methods: > > > > {$smarty->foo($bar)} > > > > For methods, you'll have to use a custom function. acceptible? > > > > Monte > > > > > > On Fri, 2003-01-10 at 03:50, André Rabold wrote: > > > Why not adding a configuration flag to Smarty to enable/disable object > > > support. The way you do it now (if I uncomment the object functionality > in > > > CVS) works great. Even if you stop supporting objects officially, it > would > > > be easy to enable it if I want it. Now I always have to uncomment it :-/ > > > > > > Thanks, > > > André > > > > > > > > > "Monte Ohrt" <monte@ispi.net> schrieb im Newsbeitrag > > > news:1041979890.30944.46.camel@lena.ispi.prv... > > > > I haven't heard much feedback on the object support. I'm leaning > toward > > > > not supporting any new syntax for it. A new syntax only complicates > the > > > > engine IMHO, and warrants further complications later. If you want > > > > objects, you'll have to use a custom function (which may get included > > > > with the distribution.) > > > > > > > > so object access could look something like this (no decisions made > yet): > > > > > > > > {object name="foo" method="bar"} > > > > > > > > If you want to use an object's output as a variable, you'd have to > > > > assign it first: > > > > > > > > {object name="foo" method="bar" assign="output"} > > > > {myfunc arg1=$output} > > > > > > > > parameters to objects will have to be handled somehow, maybe just > > > > arbitrarily... name, method, and assign are reserved, all else treated > > > > as parameters? > > > > > > > > {object name="foo" method="bar" p1="foobar1" > > > > p2="foobar2" ...} > > > > > > > > > > > > > > > > The alternative is to support object syntax: > > > > > > > > {$obj->meth($p1,$p2,"p3")} > > > > > > > > > > > > This can get pretty messy, especially if you want support for things > > > > like objects as parameters to objects, PHP functions as parameters, > > > > objects within objects, etc. I think I'd rather leave this out and > only > > > > support a limited access method via a custom function (or limited to > > > > your own concoction of custom functions or pre/post filters.) > > > > > > > > Monte > > > > > > -- > > Monte Ohrt <monte@ispi.net> > > -- Monte Ohrt <monte@ispi.net>