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.

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

Closed
bmomberger-reciprocity opened this issue Jan 10, 2013 · 7 comments
Closed
Milestone

Comments

@bmomberger-reciprocity
Copy link
Contributor

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.

@daffl
Copy link
Contributor

daffl commented Jan 11, 2013

This was done on purpose, initially to allow passing rendering functions allowing a view helper that can use can.view which is more powerful than Mustache partials.

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.

@daffl
Copy link
Contributor

daffl commented Jan 11, 2013

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.

@bmomberger-reciprocity
Copy link
Contributor Author

Thanks. That's helpful to know.

@daffl
Copy link
Contributor

daffl commented Jan 11, 2013

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

@bmomberger-reciprocity
Copy link
Contributor Author

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.

@ghost ghost assigned andykant Jan 14, 2013
@daffl
Copy link
Contributor

daffl commented Jan 15, 2013

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.

andykant added a commit that referenced this issue Jan 28, 2013
@andykant
Copy link
Contributor

Fixed.

Thanks a lot for your bug reports. Your descriptions and jsfiddles are very helpful.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants