Smarty

[boots]

EDIT: okay things are out of hand with the bb. sorry. Site Admin-- HELP!!!

EDIT: Sorry, I edited this post and it caused the poll to be deleted ?? I recreated the poll. The last results that I saw prior to this were:

1 No way
3 No, not needed
2 Maybe
1 Yes

Apologies. Please re-vote.

Hi!

I was wondering if it is a good idea to pass &$this to modifiers.

I know it goes against the idea of modifiers since it can create side-effects. On the other-hand, it gives modifiers pretty much the same power as custom functions but with a slightly simpler syntax in cases where there is only one parameter.

Here's just one example, a simple "var" modifer that emulates {assign}. The first parameter is the varname to assign to, the second paramter is either true (default) to have the modifier return output or false, for no output.

[AZTEK]

In case for some reason its needed it might be a good idea to pass it
_________________
"Imagine a school with children that can read and write, but with teachers who cannot, and you have a metaphor of the Information Age in which we live." -Peter Cochrane

[messju]

some people think it's totally wrong to have $this inside a modifier, but i am not among them.

it is hard to add $this transparently, since *all* parameters to a modifier already have meaning (consider sprintf).

with the cvs-version you can register an object's method as a modifier. this could of course be a method of your subclassed Smarty-class, or a method of an object, that knows a reference to the $smarty-object. maybe this is enough to get $this inside a modifier.

just MHO.

[boots]

[messju]

[boots]

I see, so I'd register a $this aware modifier like:

class mod_smarty extends smarty
{
function mod_smarty()
{
$this->register_modifier("var", array(&$this, "_mod_assign"));
}
...
function _mod_assign($string, $var) { ... }
...
}

That is cool. But not plug-in friendly . I like plugins because they self register. I can manage functionality by simply changing the plugins directory (poor-man's overloading).

Yeah, the array function passing looks funky, but I got used to it

I see your point on not putting object method calls in template. Not saying I'm not going to do it though, but I'm going to do more to make sure that I don't have to.

Thanks for the tips!

[Roc]

I had a need for this a few days ago. What I wanted to implement was the following:

[boots]

@Roc:

I'm doing something very similar to what you describe (I laughed when I saw "wrap" I considered that name).

Does my post here http://www.phpinsider.com/smarty-forum/viewtopic.php?p=999&highlight=#999 ring any bells??

Although, your method of passing a template looks suspiciously like an include. That means that you must be mapping a tpl var to the included template. Are params to the mod also mapped?

The plugin that I'm working on allows you to inline this kind of work by changing the meaning of modifiers depending on the modifier context block that they are in.

I like modifiers so much that I also suggested a patch to the smarty-dev mailing list to allow optional spaces in modifiers. http://lists.php.net/article.php?group=php.smarty.dev&article=1332

[Roc]

You're right, in fact what I use is similar to an include. The params are also mapped. The reason I do it this way is to make it more comprehensive to the web designers I work together with. They are mostly not programmers and should not get confused by the need to use programming techniques. The term and behavior of a "wrapper" is more familiar to designers.

[boots]

[ubaldo]

Another use of registering a method as a modifier is when writing a modifier that differs slightly from one of the standar modifiers. Let's say I want to write a modifier called my_date_format

Now, if in my_date_format you need to call smarty's standard date_format modifier, then you''ll need smarty pointer if you don't want to make a mess trying to second guess where the plugins are (see code)

require_once $this->_get_plugin_filepath('modifier', 'date_format');

I definitively could make use of a method as an modifier function.

So, is the proposed construct(see previous message):

$this->register_modifier("var", array(&$this, "_mod_assign"));

implemented?

Is it discarded?

[messju]

[ubaldo]

Thank you. Yes, I already noticed that it didn't work in 2.50. I'll give the CVS version a spin

[ubaldo]

Ok, I tried it with the following cvs versions (on top of 2.5 release tag)

1.378 smarty class
1.211 compiler class

and it seems to work fine. I'll do more testing before going to production. If you think I'm missing something or there is a potential pitfall, please, let me know.

Note: I'm using as a modifier callback a method on a smarty instance
(an instance of a Smarty class derivative, naturally)

Thank you

[messju]

@ubaldo: no i see no pitfalls here. i consider the mehod-callback-stuff stable and i am pretty sure it will stay as is for the next release. using a method of a subclass of smarty as a callback is fully legal, also.

greetings
messju