needs naming is incosistent with container lookup

[darthdeus]

As it was pointed out in #2000, when specifying a controller name for the container lookup one should use posts.index if it is the controller which belongs to a posts.index route. This works out great when using App.__container__.lookup("controllers:posts.index"), but when specifying needs

Here's a JSBin illustrating the issue

App.FooController = Ember.Controller.extend({
  needs: ["posts.index", "postsIndex"]
});

results in controllers.posts.index being undefined, while postsIndex returns a new instance of the App.PostsIndexController which isn't the one associated with the posts.index route.

This means that the App.FooController doesn't isn't able to reach into the content of posts.index controller.

[oldfartdeveloper]

I just created an issue that is very similar. My problem is that there aren't any diagnostics on this; the binding just fails and nothing tells you why.

Thanks for posting this

[rickard2]

Thanks, I can confirm this is an issue for me as well.

[heycarsten]

I've been bitten by this one too.

[ashenden]

Bitten. Halp.

[wagenet]

This should be an easy one to fix. But the question is how we should be normalizing it.

[wagenet]

I think that whatever we do here, we can probably avoid breaking existing behavior so, while we need to fix this, we can probably wait until after RC.

[darthdeus]

Since the only actual problem is that you can't use route name for the lookup, we could easily resolve this by supporting it. As you pointed out in #2000 it is not a bug that postsIndex behaves differently than posts.index.

The only problem I see here is that if we have needs: "posts.index" and then controllers.posts.index, it is not certain if we want index property on PostsController, or PostsIndexController. Even if we made the later always take precedence, it would cause the un-solvable scenarios (PostsController with detail property and PostsDetailController, which both are controllers.posts.detail).

We could say that in this case you can't simply have a detail property on the parent if the child controller has the same name. If we chose to go down the path where postsIndex and posts.index is the same thing, it would solve the issue, but it also feels like a big inconsistency with how the container works.

[endash]

How about converting "posts.index" to "posts_index" and otherwise having it behave identically. I would--naively--expect that if needs: ["postsIndex"] results in a PostsIndexController instance as a property of controllers, then needs: ["posts.index"] would also have the PostsIndexController from the container as a property on controllers as well, rather than a nested structure.

[darthdeus]

That would solve the issue, but then it's not consistent with how the container works, unless we change that as well.

[alexspeller]

This seems to be a big problem - there is no way to use needs to access a controller that is not single-syllably named atm? Does anyone have a workaround for using needs to access something like FooIndexController?

[darthdeus]

@alexspeller afaik the only workaround is to use the deprecated this.controllerFor("foo.index")

[alexspeller]

Great, thanks!

[wycats]

The solution is to have a normalize hook in the container that gets called before resolution and lookup. Ember.Application would implement the normalize hook.

[inkredabull]

Was bitten by the bug causing this but pulled and built b22afef and can now make progress.

One thing, for a controller like BarIndexController as in:

http://jsfiddle.net/Fs4DJ/1/

... is there a reason:

this.get('controllers.bar.new')

...should be undefined? I would expect 'bar.new' to resolve to the controller defined for the route.

[tonywok]

I'm running into the same issue as @inkredabull. For example, I'm not sure where to tell the container to register controller:bars.index to be App.BarsIndexController.