fix #305: do render the value "0" inside conditional

[Krinkle]

Fixes issue #305.

[Krinkle]

When the conditional block processes the path foo from the parent context with array( 'foo' => '0' ) the logic for deciding whether the value is "real" is on line 182, where it only has to pass isset().

The isset() function basically performs to checks: The variable/property/key exists, and has a non-null value.

This successfully unwraps the value '0' from array( 'foo' => '0' ).

The string '0' is then passed into the conditional closure, and Runtime::v() is called again when evaluating the placeholder {{foo}}. This time it is no longer a sub property, and it now implicitly checked by this while statement, which rejects all falsey values in PHP. Including many that isset() accepts. Such as: boolean false, number 0 and string '0'.

[Krinkle]

Build failure is unrelated, see #307.

[zordius]

Hello, This pull request breaks a handlebars.js spec test, which was definded in handlebars-lang/handlebars.js#731 . Refer to these jsfiddle:

handlebars.js 4.1.1: https://jsfiddle.net/0rec6d2f/
mustache.js 3.0.1: http://jsfiddle.net/4nLockuy/

Here are some mustache <=> handlebars difference, you can refer to these document:

About block:
https://zordius.github.io/HandlebarsCookbook/0008-block.html#BlockforFalse (search for 'Only mustache.js will think 0 as false')

About #if:
https://zordius.github.io/HandlebarsCookbook/0016-if.html (search for '0 means false')

If you like to follow mustache, the FLAG_MUSTACHE is good, you may also check the document https://github.com/zordius/lightncandy , search 'Mustache Compatibility' for more detail.

If you like to follow handlebars.js, you should use FLAG_HANDLEBARS or check the document https://github.com/zordius/lightncandy , search 'Handlebars Compatibility' for more detail.

[Krinkle]

@zordius This is about the string '0', not the number 0.

The if logic is already working correctly in lightncandy. When passing data [ 'foo' => '0' ] to {{#foo}}Yes{{/foo}} the word Yes renders correctly in lightncandy.

The problem is in the internal lightncandy logic for getting a value from a path, in ::v().

The example template:

{{#foo}}<b>{{foo}}</b>{{/foo}}

The example data:

'data' => [
  'foo' => '0',
],

When ::v() is called by the processing of {{#foo}}, the following happens:

• $data is [ 'foo' => '0' ]
• $path is [ 'foo' ] (this could also be ['foo','bar',baz'] for {{#foo.bar.baz}}).
• Inside ::v() there is a loop over $path, it is protected by a PHP if statement for $base. It sees the array as "true".
• Outcome: It is able to return the value '0'.
• Then, the logic for template parsing decides whether '0' is true for HTML template (not PHP). That logic, decides '0' is true.

Then, for <b>{{foo}}</b> we also use ::v(). There we have the bug.

• $data is [ '0' ]
• The protection PHP if statement for $base stops immediately, we never look. This means the Mustache and Handlebar logic does not have an opportunity to decide.

The value is never found, and never printed. We get <b></b>.

I might need help for a better fix. Do you have a recommendation?

[zordius]

Well, please refer to #305 , we compared handlebars.js and mustache.js there, again.

Now the handlebars.js behavior is strange but lightncandy is aligned with it. Here are some points:

1. A better fix should works on block/section context handling.
2. An issue/bug should be also created at handlebars.js repo to address this issue.
3. Based on 2, if handlebars.js will be fixed for this, then we can fix lightncandy in better way.
4. Based on 2, if handlebars.js will not change for this, then the fix will be harder because we can only fix this for mustache flag but not handlebars flag.