{{control}} vs itemController

1

I am finding it difficult to understand when to use the various rendering helpers. Consider the following example:

… post template...
{{#each comments itemController="comment"}}
  {{!-- `this` in here is each comment wrapped in a distinct App.CommentController --}}
{{/each}}

But now let’s say we have the following model’s structure:

Post hasMany Comments
Author belongsTo Comment

and let’s say when I render a Post with its Comments, I don’t need a controller for each Comment, but I do need a controller for each Author of a comment. If you do:

… post template...
{{#each comments}}
 {{ partial 'comment' }}
{{/each}}

… comment template
{{ control 'author' this.author }}

then it looks like every “descendent” author of a post is wrapped in the SAME App.AuthorController - which does not work. The only “trick” I found is to register the App.AuthorController as not a singleton. Which seems bizarre.

Is this normal? How do you guys handle this kind of scenarios?

2

I meant to add: this SO thread is related to the same question:

In short, it seems to me it is difficult to understand how to “idiomatically” deal with nested objects that don’t require nested routes. And maybe it stems from the fact I am (we are?) trying to front end relational DB based back-ends with Ember?

It would be really helpful if people could share their techniques.

3

The default for controllers is for them to be instantiated as singletons - meaning only a single controller for all instances of the associated views. To use the control tag in the way that you are doing it (which I have done) you need to tell ember not to use the controller like a singleton:

App.register('controller:author', App.AuthorController, {singleton: false });
4

{{control}} is currently still experimental. If you’re having trouble with it, it’s probably best to avoid for now until it’s cleaned up and brought out of experimental mode. We’ll also have better docs for it then.

5

It’s not surprising that it’s not clear when to use {{control}}, as it’s still in development (and therefore only available behind a flag). The answer, in general, is “don’t use it right now, unless you fully understand it and know you want it”.

Part of the process of finalizing {{control}} is also to officially answer the question of when to use {{render}} vs. {{control}}.

1 Like
6

@pwagenet ,@wycats, I totally understand that {{control}} should be used cautiously for now. But the only thing is - and I am no expert so maybe I am missing something - I don’t understand what the alternative is at present. And yet the use case seems very common. For example:

Comment has one Author

I want to render multiple comments with their author in the page, and for each of them I want the Author in its own controller. {{each}} with itemController won’t help, and {{render}} can’t be used multiple times.

Is there another way?

Again, I apologize if I am missing something completely but I definitely spent quite some time in the guides and API docs…

PJ

1 Like
7

On master, {{render}} can be used multiple times if it comes with a model:

{{render 'comment' comment1}}
{{render 'comment' comment2}}

Hopefully we’ll release RC2 soon which will have this feature.

3 Likes
8

That’s great. But what will be the difference between {{control}} and {{render}} then?

Also, on master I get a "assertion failed: This view is already rendered" when using {{render}} more than once. I submitted a pull request with a fix and test.

9

I’m sorry about that. I remembered @darthdeus submitting a PR, but forgot that I didn’t accept it. It’s now accepted.

10

The difference will be that {{control}} will have a completely isolated container. It will not inherit any context not explicitly passed into it. Its goal is standalone, isolated widgets that have the same controller/template/view structure as the rest of an Ember application.