You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See mustache/spec#179 for an issue raised on the mustache spec repository.
In brief, mustache.java renders the input data
{"a.b": "c"}
and template
{{ a.b }}
as
c
which is in a perhaps-incorrect way, although one that is not actually specified by the spec. It is likely that keys are never intended to have periods in them (see mustache/spec#67 (comment)), but again, this is not actually specified.
Note that other engines, such as both of the python ones I have checked, render this as a blank.
Note further that the current java engine prioritises a key with a period over nested data: that is, the following data renders probably incorrectly (though again, not actually counter to the specification):
{"a": {"b": "expected"},"a.b": "c"}
and
{{ a.b }}
render as
c
which is not what I would expect.
The text was updated successfully, but these errors were encountered:
I think we are in unspecified behavior land. I shouldn't change the way this works as it would be backward incompatible. Seems like an edge case. If you absolutely need to have it work differently it would be straight-forward to override the ObjectHandler. Override findWrapper with a method that returns null if the name has a . in it.
See mustache/spec#179 for an issue raised on the mustache spec repository.
In brief, mustache.java renders the input data
and template
as
which is in a perhaps-incorrect way, although one that is not actually specified by the spec. It is likely that keys are never intended to have periods in them (see mustache/spec#67 (comment)), but again, this is not actually specified.
Note that other engines, such as both of the python ones I have checked, render this as a blank.
Note further that the current java engine prioritises a key with a period over nested data: that is, the following data renders probably incorrectly (though again, not actually counter to the specification):
and
render as
which is not what I would expect.
The text was updated successfully, but these errors were encountered: