Smarty

mwhart · Smarty n00b Joined: 16 Sep 2004 Posts: 2

G'day,

I'm not sure if this has been mentioned already, but if you have a recursive object or array passed into your Smarty template variables and you have debugging turned on, then Smarty will silently (at least on my setup) die when trying to display this variable in the debug console.

Now of course one can question whether one should be using recursive data structures - but I think Smarty should gracefully fail in this case (as PHP's var_export does for example) - in this case I'm using PEAR's FormBuilder and the FormBuilder object has references to itself for callback purposes (I'm going to write to them to change this).

Here's a small change that can stop this from happening (in plugins/modifier.debug_print_var.php):

messju · Posted: Thu Sep 16, 2004 8:46 am Post subject:

this was already discussed here: http://www.phpinsider.com/smarty-forum/viewtopic.php?t=1426

i doubt it will be fixed.

mwhart · Smarty n00b Joined: 16 Sep 2004 Posts: 2

I don't see anything in that thread that indicates that it shouldn't be fixed.

I don't see why providing a depth limitation would be a problem - it could be quite a large value, and if someone really did want to change it then there could be an option.

Again, the var_export function in PHP dies when it reaches a certain level of depth, so why not just use the same functionality? It took me quite a few hours to track down the source of the browser's "Document contains no data" messages and absolutely nothing was logged, even with the error level set to E_ALL, so I really think this would help a lot more people than it would hinder - especially when using data structures that are not their own (it turns out it was the error backtrace in a PEAR_Error object that was recursing).

Is there a good reason not to have a depth limit?

messju · Posted: Fri Sep 17, 2004 7:28 am Post subject:

In the other thread Stas says: "I think it's not good idea use depth limitation."
If that is not a pretty good reason, to not have a depth limit, then i don't know.

boots · Posted: Fri Sep 17, 2004 4:13 pm Post subject:

I actually don't see why enabling a depth limit as a bailout is "bad". The main things I can think of is that it may not work (your script may consume to much ram, for example) and worse, that it does not let the developer know that they are facing a recursion issue. Without a way to determine references, the solution is open; in that case, a compromise like depth limiting may be useful to protect from unforseen issues, particularly during debuging.

Still, it is laughable that this is being triggered in a contained PEAR_Error object! Is it really necessary to include these objects in the template var space? As a rule, I'd say that application level objects have no business being reachable by the template. Still, that's not the point -- the point is that when you are debugging, you don't want your debug tools to fail!