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

Comments

Projects
None yet
3 participants
@bmomberger-reciprocity
Contributor

bmomberger-reciprocity commented Jan 10, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Jan 11, 2013

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Jan 11, 2013

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@bmomberger-reciprocity

bmomberger-reciprocity Jan 11, 2013

Contributor

Thanks. That's helpful to know.

Contributor

bmomberger-reciprocity commented Jan 11, 2013

Thanks. That's helpful to know.

@daffl

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Jan 11, 2013

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@bmomberger-reciprocity

bmomberger-reciprocity Jan 11, 2013

Contributor

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.

Contributor

bmomberger-reciprocity commented Jan 11, 2013

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

This comment has been minimized.

Show comment
Hide comment
@daffl

daffl Jan 15, 2013

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@andykant

andykant Jan 28, 2013

Contributor

Fixed.

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

Contributor

andykant commented Jan 28, 2013

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