Smarty

[c960657]

Usually variables may be used in attribute values. For example the following code will assign the value "abc" to the variable $foo, and then assign the value of $foo to the variable $bar, so that the value of $bar becomes "abc".

[mohrt]

Did you try the CVS version of Smarty? I think messju already committed a patch to throw a sensible error message when a variable is passed as the item attribute to {foreach}

[c960657]

[c960657]

_compile_foreach_start() should probably be changed to return early, when an error is triggered.

In the latest CVS version, the following two errors are thrown, if the item attribute is missing - I think that latter should be omitted:

[boots]

I actually wonder if, given $foo, we should assume the literal 'foo' and just throw a notice.

[c960657]

[boots]

Hi c960657,

I understand the issue--I'm not sure if I made my suggestion clear enough--I was only speaking of foreach, for which messju's patch solely considered.

So, given:

{foreach ... item=$foo}

I am suggesting that since we all agree that $foo makes no sense in this context and that 'foo' was likely meant, instead of throwing an error, why not just assume 'foo' and throw a notice? I don't see why that should involve semantics from other constructs.

In other words, we can be strict and throw an error (stopping processing), or we can be loose and assume the proper behaviour (proceeding with the best guess), but let the user know that is not the right thing to do. If anything, I would say being loose is more inline with PHP's design philospohy and with scripters in-general

[messju]

[mohrt]

I don't like the idea of assuming, I'd rather see an error and let them correct it.

[boots]

alright, alright--it was just an idea. I should add though that throwing a notice does give the opportunity to correct the error--it just doesn't keep things from working when we know in advance how to proceed. Sort of like not responding to someone when they say "boots" (general noun) instead of "Boots" (proper noun) even though, in context, I know that they mean ME.

Also, as far as messju's comment--I'm not sure I follow. We aren't talking about literal names are we? Indeed, are we not suggesting that the issue is with variable names given in a context where they do not make sense? Using item=$foo implies, almost certainly, that you will not be able to access the assigned item from inside the template because you would need a variable-variable. The same can probably be said about var=$foo in assign, but AFAIK, the only patch made so far was to foreach processing. If the contention is that they should be disallowed in that context as well, then I am all for that. If the idea is that different contexts can not have different rules--I'm against that. However, my only suggestion was that if the compiler can tell that $foo is senseless, it can (in theory) assume that $foo was a TYPO and that in reality, the literal 'foo' was assumed. Apply that reasoning to any context you feel it fits in.

My feeling is that the reason we see this error made at all is that people probably are used to things like foreach($arr as $k=>$v) {}

Anyways, like I said, it was just a suggestion to try to be "nice" but I can certainly see why it shouldn't be persued.

[mohrt]

I still disagree. Two humans in a discussion can't be compared to text interpreted by a parser. An assumption in a parsed syntax could easily create an ambiguous/confusing condition. Maybe this particular case is fairly safe, but I'd rather keep the template synatax and behavior consistant.

eg. I don't want {foo bar=$blah} to behave one way here and another way there.

[boots]

[mohrt]

I still think it is a good idea to force the required syntax. I'm just taking caution for the future... eg. we let "assumed" syntax slide here and there and end up creating an ambiguous situation that we can't fix.