templates can't process objects whose names contain non-alphanums

[mattbishop]

Steps:

1. Go http://akdubya.github.com/dustjs/
2. Change "name" to "first-name" in JSON object and template.

Expected value in Render Result: "Hello Mick! You have 30 new messages."

Actual value in Render Result: "Hello {first-name}! You have 30 new messages."

Please consult json.org for valid field identifiers. It allows a whole lot more than most people realize.

[drewzboto]

+1 for a fix

[ivanjensen]

+1

[ghost]

+1

[AndyNewman]

+1

[krawl]

+1 Would be quite handy given that we use dashes as word separators for our json field names.

[dlh3]

+1

[vybs]

dust templates are compiled to javascript. hence it applies the valid js identifier rules

[mattbishop]

Veena, the fact that they get compiled to JS is an implementation strategy and not part of Dust's design, which expresses a binding from JSON objects to templates.

You can accomplish the same thing compiling to key calls instead of method calls:

boundObject.jsIdentifier -> boundObject['jsIdentifier']

They are functionally equivalent and probably just as fast.

Alternately you can use a rule set like http://camelize.com/ to convert identifiers to something that will work as a method name.

[vybs]

the complied function is

it is merely a grammar artifact. Implementation of the compiler does not enforce any restrictions on the json key/reference names

function() {
dust.register("demo", body_0);

function body_0(chk, ctx) {
return chk.write("Hello ").reference(ctx.get("name"), ctx, "h").write("! You have ").reference(ctx.get("count"), ctx, "h").write(" new messages.");
}
return body_0;
})();

We probably should be able to relax it quite easily. But then we cannot support the other tokens that have special meaning in the dust grammar as identifier tokens.

Looks like "-" is the only addition. "." already has a special meaning in dust. $ is supported already, since it is valid js identifier