Re^2: Templating algorithm - pass in variables vs callback?

Hmmm - granted, some data needs to be determined ahead of time. But, to answer your questions:

CODE references which are being interpolated into a string should be considered callbacks 100% of the time. If you want to actually put in "CODE(0x1234578)", stringify the coderef first. Perhaps in other contexts, having a code ref is more questionable (say, serialisation), but I am having a hard time figuring on when passing in a code ref is going to be anything other than a callback. The callback may not be immediate - it may just be stored for future use (e.g., in Tk), but it will be called back iff the situation arises, which is no different than this - if there is no variable in the template, the callback doesn't get called.
In Re: String expansion script, I had a callback which could return a list. Perhaps you want to give your users an API to fill that says all returns are scalars - lists and hashes aren't supported. Perhaps they're scalars, but lists must be returned as array refs, and hashes as hash refs. Whatever it is, I do think that this is something that we, as a community, should try, then iron out. Like many other idioms, which sprang to existance from trial and error, I think we could end up with a very flexible and clean interface here. Heck - it could be based on XPath! :-)
If a callback dies? What happens if a hash sets a value to undef? The callback can return undef, too, I suppose, so it's not quite the same. I would think it completely reasonable to expect the callback to catch all exceptions and deal with them, or, if the callback propogates the exception (that is, doesn't use eval), it would be completely reasonable for the template to propogate it as well. Which is not significantly different from operations today.
Allow parameters? Hey, that's cool. But let's take it one step at a time, ok? :->
Eval from within the template? I'm not talking about allowing the template author to embed perl in the template (there are template managers for that already). I'm talking about straight variable substitution. If the developer who is using the template manager is concerned about safety, and doesn't think that the callback is safe, don't use it. I can't see how that would be the case - all the safety would be inside the callback. The developer then gets to tell the HTML author(s) what tags are allowed, and what they do. If the template code allows for parameters, but the callback doesn't, then the perl developer won't tell the HTML authors about parameters. If parameters are allowed, it's up to the callback to ensure the safety. If the perl developer allows a variable substitution of eval("system(q(rm -rf /))"), that is not the template manager making things unsafe - that's the callback developer making things unsafe. Treating the variables as tainted is almost as recommended here as it is for dealing with end-user text from a web form. I would hope that the html template authors would be on the same team as the perl developer, though ;-)

Problems aren't often simple - but their solutions often are ;-)

Comment on Re^2: Templating algorithm - pass in variables vs callback? Download Code

Replies are listed 'Best First'.
Re^3: Templating algorithm - pass in variables vs callback? by dragonchild (Archbishop) on Mar 01, 2005 at 16:26 UTC
I can accept that all code references are callbacks. That's not an expensive check to do. What should the template engine do if you pass a callback in for a loop variable and the callback returns a scalar after 10 iterations? Actually, upon thinking about this, I just realized I have a bug in my templating engine in that I don't check to see if the value in the looping array is a hashref. Thanks! :-) So, if the callback doesn't give the engine what it needs, just treat it like a regular failure. Ok ... I'm actually thinking that a callback dying is your damn fault, not the engine's. So, the engine shouldn't catch the errors. Parameters ... the big problem isn't passing them around, it's figuring out how to specify them. I think it's better if you pass in a CODE ref that already has the parameters for your callback specified, at least for now. I think that eval shouldn't be allowed, period. Note: While researching this response, I discovered that HTML::Template will do the right thing when passed a CODE reference for a TMPL_VAR or TMPL_IF, just like you want. But, it won't allow a CODE ref for a TMPL_LOOP. I'm sure we could provide a patch for Sam, but I have my own engine to patch. sighs Being right, does not endow the right to be rude; politeness costs nothing. Being unknowing, is not the same as being stupid. Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence. Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.	[reply]

Replies are listed 'Best First'.

Re^3: Templating algorithm - pass in variables vs callback?
by dragonchild (Archbishop) on Mar 01, 2005 at 16:26 UTC

I can accept that all code references are callbacks. That's not an expensive check to do.
What should the template engine do if you pass a callback in for a loop variable and the callback returns a scalar after 10 iterations?
Actually, upon thinking about this, I just realized I have a bug in my templating engine in that I don't check to see if the value in the looping array is a hashref. Thanks! :-)
So, if the callback doesn't give the engine what it needs, just treat it like a regular failure. Ok ...
I'm actually thinking that a callback dying is your damn fault, not the engine's. So, the engine shouldn't catch the errors.
Parameters ... the big problem isn't passing them around, it's figuring out how to specify them. I think it's better if you pass in a CODE ref that already has the parameters for your callback specified, at least for now.
I think that eval shouldn't be allowed, period.

Note: While researching this response, I discovered that HTML::Template will do the right thing when passed a CODE reference for a TMPL_VAR or TMPL_IF, just like you want. But, it won't allow a CODE ref for a TMPL_LOOP. I'm sure we could provide a patch for Sam, but I have my own engine to patch. *sighs*

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

[reply]