Support special characters as key names in dust

[vybs]

Support a use case "a.b.c" : " You are here"

Note: the json key itself has .

One way to solve is allow {a.b.c} to render the a.b.c. as the key ans not compile the same to getPath

https://github.com/linkedin/dustjs/blob/master/src/dust.pegjs

-------------------------------------------------------------------------------------------------------------------------------------
key is defined as a character matching a to z, upper or lower case, followed by 0 or more alphanumeric characters
---------------------------------------------------------------------------------------------------------------------------------------/
key "key"
= h:[a-zA-Z_$] t:[0-9a-zA-Z_$-]*
{ return h + t.join('') }

[baohouse]

Haha, my use case is worse, it has a colon in the key!
{>controlDropdown label=Messages.Plan_Account:Business /}

I'm thinking there has to be a way to either escape special characters, or to somehow specify strings for the keys.

[rragan]

Need a good syntax and then a compiler change could provide this. This might work {['string']}. It would be analogous to the ['xxx'] property reference in JS. With both the brackets and the quotes I don't think it would be ambiguous with any existing syntax.

[prashn64]

Agreed Richard.

Also, it should be combinable with our dot seperated references and arrays as well, and I think we should use double quotes to keep with current dust syntax. So I propose these be all the use cases:

{["foo.bar"]}
{.["foo.bar"]}
{["#{}'><'foo.bar"]}
{["foo".b"ar"]}
{baz["foo.bar"]}
{baz["foo.bar"].fiz}
{baz[1]["foo.bar"]}
{baz[1]["foo.bar"].fiz}
{baz[1].fiz["foo.bar"]}

Basically anything that gets put inside [""] that is contained in a reference would be treated as the literal key name and not try to do any special dust logic on it. Not putting a dot between baz and the literal reference is to keep it aligned with the Javascript syntax and the pattern already exists with arrays in dust. If you have double quotes in the key name, you would have to escape them in the template.

Does this sound reasonable/cover all the cases?

EDIT: Added {.["foo.bar"]}

[rragan]

Seems complete but you might want to add an example of {.["foo.bar"]}.

They are strings so all Unicode chars but no control chars including line breaks but see http://timelessrepo.com/json-isnt-a-javascript-subset for an edge case. What about \unnnn? Probably want it.

[prashn64]

For the line break and paragraph seperator cases, we can let whatever the generates the JSON handle it, since it's such a small edge case, so it's probably not worth adding the special replaces for them.

What's \unnnn? I couldn't find much info on it.

[rragan]

\unnnn lets you enter arbitrary Unicode value in a string. See JS string rules.

[rchawdry]

Would be nice to have. Working on a project that is converting XML to JSON for rendering. The generated JSON preserves the XML namespaces, (i.e. nc:Person), but I can't use that as is with dustjs

[ghost]

Any news on this?

Edit: How did I unassigned vybs? I didn't want to

[sethkinast]

We'd still like to do this; I have some thoughts on it once I get time to work on dust core.