Re: [SMARTY-DEV] Re: object support

This sounds like a sound solution, I like the registering idea. I think there still needs to be a distinction between function calls and object calls: {themeFoo var="foo"} This is a function call, themeFoo is the name of the registered function. So to call an object, we need to use a function designed to do so. {object name="theme->foo" p1="foo"} The "object" function is the object wrapper, it does the duty of calling the object (the step you want ommitted.) I realize this is a bit wordier than: {themeFoo p1="foo"} and doesn't mask the object model, but I think it is a good idea to make a distinction between them. This keeps the template functionality consistant, and also makes debugging/maintentance easier when you can see the difference between a function call and object call in the template. To be able to access an object, it must be registered: $smarty->register_object('theme', $theme, array('foo','bar','blah')); This will register the object by reference. The third parameter sets what methods are accessible from the template. If no third parameter is given, then all methods are accessible, except for internal methods which begin with "_" sound good? Monte On Fri, 2003-01-10 at 15:21, Bharat Mediratta wrote: > 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 > > -- Monte Ohrt <monte@ispi.net>