Add test case for dotted names

[simon-ess]

Closes #179

[jgonggrijp]

I would change the test in order to make its wording more accurate and in order to make it more defensible.

I think the original version tests for the absence of a convenience feature. The modified version as I'm suggesting it, seems more like fixing an omission and is more similar to the previous tests.

@spullara please review both the original version and my modified version. I'm told (in #179) that mustache.java would fail either version.

[jgonggrijp]

In this way, the test seems like you are purely testing for the absence of functionality. I think it is more motivating if you contrast it with the desired behavior:

Suggested change

	data:
	a.b: c
	template: '{{a.b}}'
	expected: ''
	data:
	a.b: c
	a: { b: d }
	template: '{{a.b}}'
	expected: 'd'

This is also why I suggested "No Masking" for the test name.

[simon-ess]

The only reason I caution this approach is that it still does not define what to do in the case that you have a key of the form a.b: is that a valid key or not? This is relevant for us because the java and python versions disagree: this is undefined behaviour from the spec.

[simon-ess]

That is, what should the expected output of the following be? At the moment the spec does not define that.

data:
  a.b: c
template: '{{a.b}}'

[jgonggrijp]

I think the spec defines it (in the human-oriented text), but does not test for it explicitly. If you follow the human-oriented text to the letter, I agree with you that the output should be the empty string. I also think that the other tests already imply this; they just don't enforce it.

The reason I'm hesitant to add your original version of this test, is that it actively prevents implementations from being more lenient towards their users as an added service. I understand that this is exactly what you are trying to achieve, but I'm not yet convinced that this will make the world a better place. Many implementations have extras outside of the spec, and I think this is a good thing in general. Surely, mustache.java is not harming anyone by allowing a fallback to a property by the name a.b in the context?

[simon-ess]

What we did that caused us to run into this was the following: we have a java backend that performs some templating action, and we wanted to provide a python command-line utility that did the same for users to test our templating service. The problem is, this difference means that we cannot do that; moreover, the proposed spec fix would not have resolved this issue for us either.

In a sense, the java implementation follows the letter of the spec, but not the spirit. If it is intended that keys not have periods in them, then why not specify that and enforce it?

It's not the end of the world for us; we can change the data that we use. However, the undefined behaviour in the specification means you can't at the moment have a java and python client produce the same output on the same input. Is it the end of the world? No. Can it cause people issuse? Yes.

[anderslindho]

Any news on this? I work with @simon-ess , and we would appreciate some conclusion to this.

[jgonggrijp]

@anderslindho and @simon-ess, apologies for the long silence. I was waiting for a reply by @bobthecow, but it probably escaped his attention and then it escaped mine as well. However, we can decide without his input because @spullara and I already agree.

Concluding, we will merge this. I can do it in the week of June 17-21.

[anderslindho]

Thank you kindly

[jgonggrijp]

This escaped my attention again, lots of other things on my plate. I'm writing this down and will let you know when I find another time slot.

[jgonggrijp]

I'm working on this right now.

[jobol]

I just added a related not in discussion 174: #174

It does not solves that issue but introduces a valid idea:

This current discussion might join it and many other about quoting keys or escaping characters.

I can see it is a solution: tell there is a standard escape character, say \ because it is common. So a.b is hierarchical for 2 keys when a\.b is one key.

[jgonggrijp]

@jobol Could you use backticks (`) to surround code, so that the backslash does not disappear from your posts? I currently cannot tell where you wrote a.b and where a\.b, because both appear as a.b.

Your suggestion to start an overarching discussion about escaping makes sense. Please feel free to file a new ticket for it in Discussions.

[jgonggrijp]

Released in version 1.4.2. Apologies for the long delay.