Hi,
The view is in the context of the controller it is called…but it is not observing any property change in the controller.
http://jsbin.com/qazezi/1/edit I have made this jsbin to test it. Seems that unless you call a property of controller in the init function, the observers doesnt work.
Not a bug…it was a change with Ember (not sure which version, but I think it was pre 1.0.0) that changed the behavior so that observers did not trigger on init.
What you can do instead is this:
App.MyviewView = Ember.View.extend({
func: function(){
alert('name changed');
}.observes('controller.name').on('init')
});
What you are telling will fire the func function when the page loads as the view gets initialised.
I want the function to fire every time i change a property in the controller.Thats why i have created an input box binded to name property of the controller.
One way of achieving it is to access any of the controller property in the init function of the view.I am doing it by using this.get(‘controller.name’).Ideally this shoulnt be required as view are in the context of the controller and they should be able to observe its property change.
My apologies. I misunderstood…now I’m seeing what you mean.
Another workaround could be something like this:
App.MyviewView = Ember.View.extend({
nameBinding: 'controller.name',
testObserver: function(){
alert('name changed');
}.observes('name')
});
I guess, though, you could be right that this is a bug as this didn’t really work in the way I would have expected it to…though, I’m not really sure this is something that should be happening in a view class anyway.
What is it that you’re trying to do by observing controller properties in the view?
I am making a visualisation app using d3js.In the controller i query the backend to get the data and set a property when recieved.Then i want the view to fire by oserving the change in the property and use it to generate the required graph.
Ahh…yea, I think that this might be much better suited to be a component rather than a view where you’ll explicitly pass in the data rather than binding to it.
There’s actually a few open source projects for integrating D3 and Ember (like this one). I haven’t used any…I’ve created some of my own in the past that needed a bit more flexibility…but these look like a great starting place.
Component are great …but what i want is when a user clicks on any of the child bubbles in the graph …i want it to become the main graph(.ie dril-down kind of effect).
My deisgn is to create a container view and initialse it with a child view.When the user clicks on any of the child bubbles,i will set the property on the controller which in turn will fire the observer function and append another child view(drill-down) like a tab with a close button(like we have in the browser).Using views allow me creating and destroying the graphs easily.
Ahh interesting…you bring up a good question about the limitation of components. I have a couple of thoughts…
Is this a D3 Concern?
What you’re describing wanting to do is something that D3 already does very well. What if you let D3 handle the internals of the chart? Then, when a click action occurs, your component could send the action to the controller, update the data, the component updates with the new data, etc. D3 would handle the creation and destruction of the child nodes and you would not need to handle any view hierarchy with Ember.
Should there be a ComponentContainer Class?
I was looking into EmberUI and I found that they were doing some interesting things for pop-over type components. It looks like they want components to programmatically append and remove sub-components…and since you can’t really do that, they have a nifty workaround where they manually append a new component to the <body> and position it.
The advantage here is that those sub-components do not need to be rendered initially…but should be rendered when the user wants to interact with it. The disadvantage with the current implementation is that there’s a bit of hackery by using the container directly and not a clear way of handling bubbling actions.
Anyway…my thoughts. Any thoughts of your own?
Hey,
finally figured it out http://jsbin.com/loxuki/15/edit
Seems that you have to manually add the observer function in the view.About using component i am still not sure because there is very little you can do with components.They are just like widgets which you can configure.
What if i want to merge two bubbles on the graph into one(they are similar)? Using Components wont be possible.
Actually, there’s a pretty clear reason why this is happening (finally cracked open the source code to take a look).
By default, a view’s controller will inherit it’s parent controller through a calculated property. You can see how that works here. Observers do not trigger on calculated properties until they are accessed for the first time. So, this behavior is not a bug, it is working exactly how it’s supposed to (though in this case, it does seem unintuitive).
Components can be very powerful. I have (and others have) done some pretty sophisticated UIs leveraging components…And, perhaps, rather than thinking about your graph as a single component, you could think about it as a bunch of smaller components that can interact with one another through their parent component…(there’s good talk about doing that here).
But, we still face the problem of not being able to programmatically add or remove child components…that would be a really nice feature. 
@knaman2609 you probably want to use this.createChildView(this, options) instead of view.create(options), for a container view.