Re: [SMARTY-DEV] Re: object support

So what if we support both methods? The preferred method of using objects will be to register them and use them like regular template function calls. This has several limitations, but will probably work fine for typical use, and _especially_ those of us who have to train and support a diverse field of template designers. OTOH, If you want to access an object directly in the template, Smarty will recognize and support that as well. Supporting OO syntax in the template is not a technical barrier, the whole issue is requiring a new syntax for the HTML designers to understand just so we can support object access. So two ways to use objects: PREFERRED, PREACHED METHOD: 1) Registering of object methods as template functions: php code: $smarty->register_function('themeFoo', array(&$theme, 'foo')); template: {themeFoo p1="foo" p2="bar"} NOT PREFERRED, BUT SUPPORTED METHOD: 2) assign objects, access them directly: php code: $smarty->assign_by_ref('theme',$theme); template: {$theme->foo("foo","bar")} It will be clearly stated in the manual the difference between the two methods, why use one over the other, etc. We already have issues like this in Smarty, where there is nothing stopping you from mixing PHP code in the templates but it is highly discouraged, so this really wouldn't be any different. Would this satisfy both sides of the fence? Monte On Wed, 2003-01-22 at 03:40, Nick Charsley wrote: > > > > I do, however, perfectly understand the argument that designers > > shouldn't be burdened with knowledge about OOP, but why would this > > syntax require that? If you're working with designers that shouldn't be > > exposed to OOP, you just go about business the old way, and assign > > things in bits and pieces. Nobody would force your hand in using this > > more advanced syntax if you felt it wasn't right for your audience. > > > Typical, I was just about to say exactly this. If your HTML monkey will not > get to grips with a new syntax don't frighten her with it. Possibly to avoid > problems this should only go in an appendix to the Manual (when it's added), > otherwise it will become a bandwagon an everyone will try and use it. I see > this as an advanced feature which rounds some of the missing corners of an > otherwise first-class piece of software. > > Yes the syntax should be as close to the syntax we currently have, but we > mustn't be lead in to thinking providing direct Object support is > unachievable because we cannot see a way to fit it in without extending the > syntax. At the end of the day this is probably going to be more useful to > the PHP programmer who is also designing the pages, so a PHP like syntax is > what he expects. If its a fresh HTML monkey and the whole site is using > objects then the syntax is going to be the only one she learns. In mixed > sites there is going to be some possibility for confusion, but when I first > used a provided API I had to check the syntax for every call, now I know > then, and the Monkey will soon learn what requires which syntax. > > Monte's complicated but valid syntax is I feel what we need for the Object > support. > > Nick (c) > > obviously a "Object support in Smarty" zealot > -- Monte Ohrt <monte@ispi.net>