-
Notifications
You must be signed in to change notification settings - Fork 422
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.
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
Mustache: Inconsistent treatment of function attributes #231
Comments
This was done on purpose, initially to allow passing rendering functions allowing a view helper that can use Since Handlebars works exactly the same way (functions passed to helpers won't be evaluated) and it isn't part of the official Mustache specification I would say this is the expected behaviour anyway. |
Ah, I think I know where the inconsistency is. Handlebars doesn't evaluate functions at all when called with nested attributes. Your first example looks already different with Handlebars, see this Fiddle. |
Thanks. That's helpful to know. |
Do you consider this something that needs to be fixed? In theory Handlebars templates are still compatible with can.Mustache in this case (just not the other way around). |
Citing the goal of Handlebars compatibility, I think it's just something that needs to be documented, perhaps with workaround examples (e.g. using subsections, or passing the path as string and using can.getObject with string parsing to find the function's parent object). The can.Mustache docs (donejs.com and canjs.us) have no mention of using functions in the Handlebars style; since I don't have prior expertise in Handlebars, I wasn't even aware that it was possible until my coworker showed me the issue. |
I think we found a nice solution that still maintains Handlebars compatibility. We will continue passing functions to helpers but will make sure that they are always bound to their actual context. This should solve your issue and will also clear up a lot of confusion regarding the current context. |
Fixed. Thanks a lot for your bug reports. Your descriptions and jsfiddles are very helpful. |
http://jsfiddle.net/cjzaT/2/
A function accessed by the transformation (default) hookup will execute in its member context (parent object as this) and resolve to a value. By contrast, when a function attribute is hooked up to a custom helper, it is passed as a function object without context (i.e. not proxied). Since the path to the function's parent object is not available to the helper, this makes it difficult (but not impossible -- see workaround in linked jsfiddle) to make helpers that work with member functions at arbitrary levels.
Credit to user danring for discovering this issue.
The text was updated successfully, but these errors were encountered: