Re: [SMARTY-DEV] Re: object support

Sorry to weigh in on this so late in the game :-( I like the fact that Smarty is incorporating object support. However, I am not thrilled about the fact that template designers need to understand object dereferencing syntax in order to use them. I'd rather see us continue with the standard Smarty model where we provide a series of {commands} that are mapped to functions() in the code. This frees the template designer from having to understand anything about the object model; they simply continue using Smarty functions as before. I do this in Gallery 2.x, currently. I have a class: class theme { function foo($params); function bar($params); } I register calls something like this: register {themeFoo} to call $theme->foo(); register {themeBar} to call $theme->bar(); So in the template, this is represented as: {galleryFoo p1="blah" p2="blah"} To the template designer, this looks just like any other Smarty function. They don't have to have a clue about the object model. This also means that new methods added to the object model don't automatically become available to the template designer, unless the code explicitly makes them available. I particularly like this; it keeps the template designer confined to the API you give them and keeps him or her from straying where they don't belong. All of this is possible if we are allowed to register object methods as callbacks, instead of just being able to register functons. In Gallery 2.x I have to register a delegate function which receives all callbacks and then delegates them in turn to the appropriate object which is an extra layer I'd like to avoid. regards, -Bharat From: "Monte Ohrt" <monte@ispi.net> ... > 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> > > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php >