Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add test case for dotted names #180

Merged
merged 3 commits into from
Aug 12, 2024
Merged

Add test case for dotted names #180

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ae03141
Add test case for dotted names
simon-ess Nov 22, 2023
fb025bf
ADd test for masking of dotted keys
simon-ess Nov 27, 2023
7358dd5
Reword test name and description
jgonggrijp Aug 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
15 changes: 15 additions & 0 deletions specs/interpolation.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -197,6 +197,21 @@ tests:
template: '{{#a}}{{b.c}}{{/a}}'
expected: ''

- name: Dotted Names are never single keys
desc: Dotted names shall not be parsed as single, atomic keys
data:
a.b: c
template: '{{a.b}}'
expected: ''
Comment on lines +202 to +205
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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}}'

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you kindly

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on this right now.


- name: Dotted Names - No Masking
desc: Dotted Names in a given context are unvavailable due to dot splitting
data:
a.b: c
a: { b: d }
template: '{{a.b}}'
expected: 'd'

# Implicit Iterators

- name: Implicit Iterators - Basic Interpolation
Expand Down