cannot use string of integer as id

[lokkilok]

It's my first few hours working with Handlebars, so I may have missed something, but.....

With data like this: {status: {"200": 4, "304": 10}} it seems that one cannot access those entries with string representations of integers as keys. This template doesn't work for me (using the 1.0.3beta package):

{{#with status}}
{{#if 200}} OK: {{ 200 }} {{/if}}
{{/with}}

the {{ 200 }} results in a Parse error "EXPECTING ID". The same happens when the template contains: {{ "200" }}. Curiously the {{#if 200}} seems to work fine.

[wycats]

In Handlebars, integers tokenize as INTEGER. You can make any sequence of characters work by surrounding them in brackets:

{{#with status}}
  {{#if [200] }} OK: {{ [200] }} {{/if}}
{{/with}}

[santip]

good to know the brackets help as a workaround, but I wanted to point out that this behavior breaks backwards compatibility with mustache.

I had mustache templates where I would access array elements by literal indexes by writting:

{{someArray.0}}

However, when I tried to migrate my app from mustache to handlebars (assuming the templates should all work) I found myself with tons of errors

`Expecting 'ID', got 'INTEGER'``

Luckily, changing those expressions to

{{someArray.[0]}}

fixed the issue. perhaps it's worth it extending the language a little bit to support this experssions for mustache-compatibility.

Thanks

[wycats]

@santip I'm confused. Mustache doesn't support paths at all, so how could you be doing {{someArray.0}} in mustache?

[santip]

aww, my bad, ok, I was actually using hogan.js and didn't know it wasn't supported on mustache.

btw, when migrating from hogan.js I also noticed that bubbling doesn't seem to quite work as it did in hogan (or mustache):

Handlebars.compile('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}')({a:1, b:[{c:2}], d:3}) == 'aaa 1 2'

Hogan.compile('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}').render({a:1, b:[{c:2}], d:3}) == 'aaa 1 23'

Mustache.render('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}', {a:1, b:[{c:2}], d:3}) == 'aaa 1 23'

It works when I use ../ which is the reason why I switched to Handlebars but I thought it was worth pointing out the lack of compatibility there.

[santip]

Also I just tested out mustache and it does seem to support paths

Mustache.render('aaa {{a}} {{b.c}}', {a:1, b:{c:2}, d:3}) == 'aaa 1 2'

[jontro]

Yes, mustache supports paths. Check the # Dotted Names in https://github.com/mustache/spec/blob/master/specs/sections.yml

[wycats]

Seems like mustache has been adding features. I am unsure if I signed up to track the Mustache spec forever :/

[wycats]

It doesn't look like the Mustache spec describes behavior for .<integer>. I could definitely make this work, although Handlebars' foo.[anything] works better for non-identifier paths.

My original plan was "if it is a valid dot-path in JS, it works in Handlebars".

[santip]

Is there any reason why you couldn't support the .<integer> path notation?

I don't think you should support bubbling because it would probably break many existing handlebars templates, although you should probably update the docs and site to inform about these incompatibilities to save some headache for people doing the migration.

[georgecrawford]

I ran into this when trying to use identifiers in the form {{1}}, which compile fine in Mustache and Hogan but throw Expecting 'ID', 'DATA', got 'NUMBER' in Handlebars. Although I'd like integers to be supported, I totally understand and support @wycats approach of using only valid JS dot-path syntax.

However, I do think the docs should reflect this. They currently state:

Identifiers may be any unicode character except for the following:
Whitespace ! " # % & ' ( ) * + , . / ; < = > @ [ \ ] ^ ` { | } ~

which I think is misleading as integers aren't valid. It's much clearer to say "if it is a valid dot-path in JS, it works in Handlebars", as suggested.

http://handlebarsjs.com/expressions.html