emberjs/ember.js — pull request #915 by christophersansone (2012-05-30 21:19:28+00:00)
Title: Custom Handlebars helpers allow *Binding properties to be non-strings

Maybe there is a more proper way to do this, but this was working as of 0.9.6 and fails in 0.9.8.

I have written a few Handlebars helpers that are modeled after {{view}} and create an instance of a particular view class. For example, I have a {{date}} helper that, when given a Javascript Date object or an ISO string, will output an instance of a custom DateView class, perform the necessary display conversion via a computed property of the view, allow bindings for changing date values, etc. Basically the following:

{{date content.date}}

... is the equivalent of ...

{{view DateView valueBinding="content.date"}}

In my Handlebars.registerHelper(), I set the binding as such, before creating the view via ViewHelper.helper():

options.hash.valueBinding = Ember.Binding.oneWay('bindingContext.' + id);

This now breaks due to a recent code change that expects *Binding properties to only be strings. This pull request fixes the issue.

Under normal circumstances, I can see how *Bindings would almost always be strings, since this is normally called within a template. However, in situations such as mine, the binding may very well be an actual Ember.Binding object.

Again, if I should be doing it a different way, I am all ears. And I could obviously resolve it by just defining the binding as a string, but then it would have the extra overhead of the two-way binding. But at any rate, it seems like a small defect to me.