Consistently use the new view registry

[ef4]

Internally, the EventDispatcher looks for the global view registry on the container and then falls back to using View.views. Since we were creating it directly instead of via the container, it had no container reference, and so it was doing all view tracking using the fallback.

This is problematic, because the global fallback path is now only accessible from inside Ember (by design, because we're trying to eliminate it.)

[rwjblue]

Looking up the EventDispatcher from the container (as you changed above), should be sufficient to ensure that it internally has access to -view-registry:main, we should not need to set the internal Ember.View.views.

Was this left over from before you changed context.dispatcher to be looked up?

[ef4]

No, this was necessary. Ember is internally using the View.views list still, and it only copies that list out of the container during app instance initialization.

Our integration tests don't go down that initialization path.

[rwjblue]

In all cases Ember should be using -view-registry:main then falling back to its internal View.views. The -view-registry:main is setup during Ember.Application.buildRegistry (injection is setup directly below) which we are calling from here. Since the EventDispatcher is now being looked up from the container (from the other changes in this PR) that is built with -view-registry:main it will be have a container and be able to do this.container.lookup('-view-registry:main') (here).

Where in Ember are we still using View.views without checking -view-registry:main first?

[ef4]

Ah, I think I see the problem. ember-test-helpers is doing a Component.create, and although it passes in a container, that is insufficient.

To play nicely with dependency injection, ember-test-helpers should be doing lookupFactory instead. Is there a generic component factory available? Something equivalent to the old view:default?

[rwjblue]

No, I don't think something like that exists, but the following code should work for us here:

var thingToRegisterWith = this.registry || this.container;
thingToRegisterWith.register('component:-template-under-test', Ember.Component.extend({
  layout: template
});
module.component = this.container.lookup('component:-template-under-test');

[ef4]

This gets weirder. Even if I use lookupFactory, _viewRegistry is only injected onto things registered as view:foo, not things registered as component:foo. That seems like a potential Ember bug, although it doesn't effect a normal app since they use view:toplevel (not component:toplevel, and then each view inherits a viewRegistry from its parent.

[rwjblue]

Yeah, I agree that this should be fixed upstream in Ember (we should inject -view-registry:main into both view and component), but the solution with the smallest amount of change might just be:

module.component = Ember.Component.create({
        layout: template,
        container: module.container,
        _viewRegistry: module.container.lookup('-view-registry:main')
      });

We should still fix that injection upstream though....

[rwjblue]

I'd like a test that we can use to help prevent regressions here. Seems like this bug prevents testing of event dispatcher handled events, right? I can try to PR a test against your branch if you'd like...

[ef4]

We actually have test coverage for event dispatching, and the bug wasn't breaking the tests because it was canceling itself out. All the views were being placed on View.views, and that's where the event dispatcher was expecting to find them.

I only noticed a problem due to ember-mobiletouch failing to find this.container in the event dispatcher.

So I don't see a good test for this condition that doesn't peek into internals and test things that don't really matter to users. This issue was really about upgrading the test helpers to use newer internals.