There are many different flavors of Model-View-Controller, but they all have the same goal of separating the concerns of decision making, managing state, and user interaction. Better still if we can avoid any situation where the model and view are dependent on each other. The MVC flavor I like best, and use when the choice is left to me, is the one identified by Martin Fowler as
Passive View. Here the controller is the only observer. It watches everything and makes all the decisions. It knows that if the model is being updated because of a change in the View, the view does not need to be redundantly updated, and vice versa.
Jon Swanson wrote:Panel 1 gets user data, calculates d, sets new observable data
Panel 2 gets update, updates its view, calculates new data, sets new observable data, oops, now Observable is telling it there is new data again- the data it just put in.
You are giving your Panels too much responsibility. View components should display data and take user input. They shouldn't do anything else. Calculations should be performed in the model or by the controller. There are differing schools of thought about what a model should be. Some people prefer a model to be an object with attributes, getters and setters, and no other methods. With this kind of model, all logic would be performed by the controller. Another way to organize things is to keep logic in the model as well; with this design the model is a little community of related objects, together with the methods that are needed to use them together.
Here's how I think your scenario ought to look:
Panel 1 gets user data.
Controller is notified of the change.
Controller gets the values from the table.
Controller updates the model.
Model calculates d.
Controller gets d from the model.
Model calculates values for Panel 2.
Controller updates Panel 1 and Panel 2.
The thing to notice here is how the controller is doing the heavy lifting, and the view and model just do what they are told.