Core Team Meeting Minutes - 2014/04/04

– By Robert Jackson

Although most of our collaboration takes place on Github, IRC (#emberjs on, and our Discourse site the Ember.js Core Team meets privately every Friday at 2pm EST/11am PST through Google Hangout for a weekly discussion of all things Ember.

If you have a topic you'd like to see covered, contact your favorite core team member and let them know!


@ebryn, @krisselden, @machty, @rwjblue, @wagenet, @tomdale


PR's/Issues To Review

  • BUGFIX beta Allow setting of undefined value to a content property

    Fixes setting of undefined value to a content property.

    Still, checking obj[keyName] === value in these lines is bypassed in two cases

    • If the setter value is undefined
    • If the setter property lies inside the proxied content

    Using get(obj, keyName) might resolve. But was quite nervous to do that as it may involve some additional function calls

    +1 by @stefanpenner, but he requests @krisselden to review.


    Seems good, but @krisselden will review in further detail. Will attempt to have this update in 1.6.0-beta.2.

  • BUGFIX beta Ensure context is unchanged when using keywords with itemController.

    Prior to this change the following code would bind this in the template block to the itemController's content (even though the keyword form of {{each}} is used).

    This change sets the child view's _context property to the current context when using the keyword form of {{each}}, and a couple of confirming tests to demonstrate using itemController specified in either the ArrayController or the template directly.

    Failing JSBin | Passing JSBin

    Fixes #4634.


    The intent of the each foo in bar syntax is specifically to preserve the current context. However, using each foo in bar syntax along with an itemController has always changed the inner templates context. This change seems good, but all context related changes require a bit of additional review. @krisselden to review further and +1/-1.

  • BUGFIX beta {{view}} helper no longer uses Ember.View global, instead uses container view:default

    During the ES6-ify process @rwjblue left a comment mentioning that the {{view}} helper needs to not look up Ember.View globally. This PR fixes this by looking up view:default from the container (which Ember.View is registered at, by default).


    Looking up view:default in the container is definitely more appropriate than hard-coding to Ember.View.


  • BUGFIX beta Add better debugging for DefaultResolver.

    Adds nice log entries if your application was created with LOG_RESOLVER set.

    Example log entries:

  [ ] route:application ..........................................  App.ApplicationRoute
  [] route:index ................................................  App.IndexRoute
  [ ] controller:application .....................................  App.ApplicationController

Fixes #4654.

Example JSBin (look at console)


This adds good insight into exactly what the resolver is doing and what you need to implement to add custom behavior. In the future, a better API needs to be created to enable these logging options (hanging a bunch of properties off of the application instance is sub-optimal).

Merged (will be in 1.6.0-beta.2).

  • FEATURE ember-handlebars-radio-buttons Implement radio buttons

    This updates #1235 to extend component, adds handlebar helpers, updates tests and documentation. I think a lot of people would be pleased to see radio buttons in the core and I see a lot of developers at my company have a hard time with radio buttons when they first get started with Ember, so I think this would be a great addition to the core.


    We would prefer for this to live as an addon for a while to allow the community to test (and influence) the API.

  • Transitioning to a globbing route does not work

    I think it's a corner case, so I don't know if this should work, or if you would fix that. Anyway, in my application, I'm defining a notFound route, hit when the user plays with the url and gives something wrong. I also want redirect to this route when the user try to access an unexisting record (ie the backend answer a 404). So I tried to define an error handler in the ApplicationRoute, and transitionTo('notFound'). Unfortunately it does not work. Though if I remove the globbing path, then it works for the redirection, but not when entering unknown url.

    I made a jsbin reproducing it: here


    It is possible to transition to a globbing route, but like any target route with a dynamic segment, you need to provide a object / param, which in this case can be a string of the path you want to use for that globbed segment:

    this.transitionTo('yargle', "MY/COOL/URL");