-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ArrayController
always returns the same instance when using itemController
#2009
Comments
Just cleaned up the example a little bit |
@josepjaume, looks like you have a naming conflict here. |
We should warn about this conflict somehow. Once I had spent about 30 minutes to reveal this mistake. |
I'm not sure of the best way to resolve this issue directly though we have -Peter On Feb 9, 2013, at 1:31 AM, Andrey Ivashchenko notifications@github.com We should warn about this conflict somehow. Once I had spent about 30 — |
Now that I think about this more, this may still be a bug. I'll reopen for now. |
Hi @wagenet, I think it makes sense to use the same controller as your "show" route. So either this should be filed as bug or For example, I can clearly see the case where I want to store some application state in a particular Thanks! |
My case scenario is the following: I want to reuse the same instance of the controller on the list or in its "show" route, because I want to store some application state in each one. After giving it some thought, it seems like the issues start here, at If I do understand it well, it will create a different instance of itemController for each item and cache it in the The visibility of this Shouldn't this |
So here is a possible work around http://jsfiddle.net/sSdHm/66/ I definitely agree the behavior is surprising, especially the fact that it works on the first list render. This is the explanation, what is the right thing to do, I am not sure. I get the case of reuse of controller in the show route. Seems like a valid idea. Seems like the solution would be to pass in to the route the caller controller container. It could work, but I am not sure about all the semantics. |
Thanks for shining some light on it, @tchak. I actually ended up doing something like your fix, but inheriting a whole controller instead. Your workaround looks nicer though. Yet as you point out this doesn't solve the case when you want to store something in the controller. I think this is kind of an important issue to solve, specially since the Ember team seems to be encouraging using controllers to store application state: It would be awesome to do something like storing the controller's variables in a Client-Side HTML5 storage in a seamless way, for example. |
@josepjaume the only clean way of doing it I see is using current controller container in the route. |
@josepjaume I think my PR solves your use case |
@tchak sorry but it doesn't seem like it :( |
@josepjaume you have to change |
Hmmm... Still doesn't work: http://jsfiddle.net/josepjaume/MxQnq/1/ Sorry! |
@josepjaume I am sorry I forgot about the |
There is one doubt left. The |
For now, I think the workaround is to not use the same name. In this case, if you want to share, make a subclass of |
@wagenet this is exactly what I did. Maybe we should use separate container for item controllers? |
@caligo-mentis I believe we do use a separate container but there's an inheritance issue for lookups. I'm not entirely sure how the internals work here yet. |
Can anyone confirm if this is still an issue on master? @wycats, any thoughts? |
Closing due to inactivity. If this is still an issue, please open a new ticket. |
@wagenet we don't use a separate container. Sub Container life cycle pining proved a serious blocker to do entirely transparently. We will likely re-visit. Also, unless im doing something wrong, the jsfiddle works fine on the latest release, so the problem seems to be resolved. |
Here's a fiddle:
http://jsfiddle.net/josepjaume/sSdHm/47/
Steps to reproduce:
Click on an element and go back. You'll see the controller is always returning the last instance.
The text was updated successfully, but these errors were encountered: