Hi Avi,
I've noticed a related issue. Say you have a template defined by a helper that returns a template:
Handlebars.registerHelper("foo", function fooHelper() {
console.log(this);
var templateName = figureOutNameDynamically(this.criticalInfo);
return Template[templateName];
});
So I need the "criticalInfo" property from the calling context to determine which template to render.
Scenario 1 (works fine):
{{> foo objWithCriticalInfo}}
Scenario 2 (works fine):
{{#with objWithCriticalInfo}}
{{> foo}}
{{/with}}
Scenario 3 (does not work):
{{#with objWithCriticalInfo}}
{{> foo extraKeyword=bar}}
{{/with}}
Scenario 3 doesn't work because as soon as keywords are detected, they are merged into an object and that object becomes `this` rather than the calling context. In fact, there is currently no way at all to get the calling context from within the helper function if keywords are used.
A workaround is to do this:
{{#with objWithCriticalInfo}}
{{> foo extraKeyword=bar context=..}}
{{/with}}
Or this (in this particular example):
{{#with objWithCriticalInfo}}
{{> foo extraKeyword=bar criticalInfo=../criticalInfo}}
{{/with}}
However, this should not be necessary, and in my case it would cause confusion for users of my package. My proposal is that when `this` is overridden by a keywords object, the helper function should receive the data context in an argument. I made
a quick change to this effect that works in a branch on my fork, but I'm almost positive my change is not the ideal way to solve, so I'm bringing this to your attention rather than doing a PR.
Another option would be to have keywords extend the default context rather than replace it. This could lead to some interesting abilities, but it might be confusing.
Thanks,
Eric