I just want to open up a discussion around how this could possibly be implemented and what the api would look like (especially in light of the new injection container and router).

The canonical use case for this is in conjunction with an {{each}} helper that requires an ObjectController for each item.

As it stands, I can think of two ways to implement this:

1. Use a custom Ember.ArrayProxy subclass which wraps each item in its content in a controller. This subclass intercepts array change events to handle bookkeeping of the controllers. (This is the method I currently use in my apps.)
2. Use the injection container with non-singleton controllers. Simply register the controller in the container as a non-singleton and do lookup as normal. The open problem here is where and when to cleanup these controllers.

With option 2 in mind, consider the following handlebars snippet:

{{#each item in this}}
  {{render 'item' item}}
{{/each}}

This assumes the existence of the {{render}} helper (see #1628) and I also think it would be good to eventually give {{each}} render semantics, but this snippet is helpful for discussion.

If a controller is registered as a non-singleton with the container, then this snippet should hypothetically function as expected. In fact, this has the added benefit that things like {{render}} could be entirely agnostic as to whether there is a singleton or non-singleton controller backing it. The only problem is that these non-singleton controllers will never be destroyed.

Therefore, in order for option 2 to be viable, there needs to be some mechanism to track these controllers and clean them up when appropriate. Three possibilities that immediately come to mind:

• Bookkeep at the view layer
• Bookkeep at the route level
• Bookkeep at the content layer (e.g. on a per-model basis)

The view layer is a poor option due to the fact that the controller would be destroyed during re-render.

The route level could be plausible but seems unnecessarily tied to the routing system.

Perhaps, book-keeping on a per-model basis is the best option? The render semantics could be such that for non-singleton controllers, a listener is created that destroys the controller at the same time the model is destroyed? Once ember-data has some sort of store/cache clearing mechanism I can see this making a lot of sense. This is also in some ways very similar to using an ArrayProxy.

Thoughts?