mustache / spec

The Mustache spec.
MIT License
361 stars 71 forks source link

The specification does not specify how to handle tags with periods in them #179

Open simon-ess opened 8 months ago

simon-ess commented 8 months ago

Consider the following data:

{"a.b": "c"}

and the template

{{ a.b }}

What should this render? According to the two python implementations (https://github.com/noahmorrison/chevron, https://github.com/defunkt/pystache) I have seen, it renders a blank, since a.b in the template is looking for a structure of the form

{"a": {"b": "c"}}

However, the java implementation we use (https://github.com/spullara/mustache.java) the output instead is

c

In fact, the same is the case if you use input data such as

{"a":
  {"b": "d"},
 "a.b": "c"
}

where the key a.b overrides the nested structure (which seems like the wrong choice to me, given the options).

The problem here is that this seems to be undefined behaviour: the spec never defines what to do with keys that have periods in them, which leaves individual engines up to their own devices on how to handle it. There is an open issue which implies that one should not do this, but it is not explicit: https://github.com/mustache/spec/issues/67#issuecomment-53523219

It would be good to have this specified, to ensure consistent behaviour between various engines.

jgonggrijp commented 8 months ago

Is this really unspecified? I mean, the interpolation and section specs are rather explicit about how dotted names should be resolved. I don't think the specs allow for mustache.java's behavior.

simon-ess commented 8 months ago

Well, see https://github.com/spullara/mustache.java/issues/297#issuecomment-1821852641 for their response to this issue.

The behaviour is, in my opinion, undefined as there is no formal specification that I could find for what a well-formed key should be. All of the keys are alphanumeric strings with no special characters, but it doesn't say that those are the only allowed characters, which in theory permits keys of the form a.b.c.d.

simon-ess commented 8 months ago

(It's worth noting that we ran into this as we were using a filename as a key, which worked as we naïvely expected in the java implementation, but then broke when we switched to a python engine)

jgonggrijp commented 8 months ago

These are the relevant parts of the interpolation spec. The section spec has similar wording and tests.

https://github.com/mustache/spec/blob/83b221aec50adb91eeaa935ba7bd51cd792daece/specs/interpolation.yml#L7-L22

https://github.com/mustache/spec/blob/83b221aec50adb91eeaa935ba7bd51cd792daece/specs/interpolation.yml#L142-L198

simon-ess commented 8 months ago

Ah, fair point, there is a description there. However, there are no tests that actually verify this. It might be good to add a test of the form

  - name: Dotted keys
    desc: Dotted keys should not be treated as standalone keys
    data:
      a.b: c
    template: '"{{a.b}}" == ""'
    expected: '"" == ""'