Re: [SMARTY-DEV] Re: object support

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>