Ember.getById for getting view instantiated objects

[guilhermeaiolfi]

I would kie to suggest a feature I think would nice to have: ability to get any instantiated view object programatically.

For example:

Having:

<script type="text/x-handlebars">
    {{#view Ember.View id="12" propertyA="1"}}text{{/view}}
</script>

I would be able to access this instance and change propertyA to "2" for example.

Here is some code to illustrate: http://jsfiddle.net/rUUuN/3/

That works, but I think it's unsafe to use id="" like that, propagating this ID all the way down to the DOM. Maybe another metadata id, that would be used just for these cases with a getById function:

var myView = Ember.getById('12');

So maybe in the future we could have a Ext.query() equivalent [1].

[1] www.sencha.com/learn/domquery-v11-basics/

[wagenet]

@guilhermeaiolfi Can you provide a use case for this? It seems like normally you shouldn't be referencing views globally.

[guilhermeaiolfi]

@wagenet Nothing specific right now. But let me see:

• imagine a button somewhere that when clicked should changed the current view in a dock layout.
• a button in a form that would close a window view.
• toolbar button that would set the selected item in a list to another color.
• a toolbar button that would remove the selected item from a gallery view.

There are so many cases I would use this feature I could list much more cases but I hope you get the idea from these.

I would be interested to know you do this currently.

[wagenet]

I think most if not all of this should be done with bindings and event handlers. I may be mistaken but I'd have to see a more specific case to be convinced.

[guilhermeaiolfi]

Have you seen the jsfiddle? It was based on this simple simple custom view I had and I was willing to get the value of one of its properties to show it in a alert() call?

Here's a jsfiddle updated to show it better: http://jsfiddle.net/rUUuN/4/

How would you do that without using Ember.View.views and messing with ember's ids?

[wagenet]

In your jsfiddle you should bind propertyA to a known value and then your func should update that value instead of attempting to update the view directly. Here's an example http://jsfiddle.net/MSffL/1/.

[wagenet]

I'm closing since I don't think the proposed solution is the right way to handle this scenario. If you have another example, let me know and I can consider reopening.

[guilhermeaiolfi]

It seems more complex than it should be. I mean, a controller + binding to simply get a view's property?

But lets think in another scenario then. There are cases where methods need to be called in the view and a binding wouldn't work. For example, imagine a view that represents the status of my app, that would show every operation that goes wrong to show to the user when it feels necessary. In this view I have a method statusView.addMessage(ICON, MESSAGE, OPTIONS). If an ajax request goes wrong, status.addMessage is called inside the store adapter. If another operation throw an error, status.addMessage is called. etc.

Sorry if I'm being insistent but I think we need this kind of power because it's how we (web developers without sproutcore background) are used to create apps: .getElementById(), $('#id'), etc. Maybe there is an ember way to do all this. Feel free to close this issue if you think the idea is not worth.

[guilhermeaiolfi]

But then again, if I have a statusController I could have a array of messages bound to the view and use the controllers .addMessage() to update the view, right?

I think I'm starting to get the idea: views + controllers, always.

All right, issue closed. Sorry for the noise and thank @wagenet for your time.

[benatkin]

I was disappointed that I didn't have an easy way to pull up a view object in Chrome Inspector. So that's my use case.

[wagenet]

@benatkin Ember.View.views.ember###

[benatkin]

Thanks; makes sense.
On Jan 14, 2012 11:12 PM, "Peter Wagenet" <
reply@reply.github.com>
wrote:

@benatkin Ember.View.views.ember###

---

Reply to this email directly or view it on GitHub:
#366 (comment)

[guilhermeaiolfi]

Hi, I have another user case for it.

In this user case it doesn't make any sense to put the data into the controller:

http://jsfiddle.net/5n2LU/7/

Look what I had to do. And because of another bug in ember's views I would have to call [view instance].rerender().

IMO we create something like I suggested in this bug or we allow instances in the view handlebars helpers. That would eliminate the need of some bindings and indirect functions calls, making the whole thing faster.

I'm doing what I'm doing in the jsfiddle because I want to load modules async from the server and render them in a pre-determined container depending on the user interaction.