We are designing a builder type application where the user adds/removes/configures items on a canvas.  The view that the user creates is backed in the model with a definition which can be saved/retrieved.  There are multiple parts of the view which can update the model and need to be aware of changes to the model.  In addition, the model can be updated from the server side as a side-effect of a view change.

Whenever the model changes (either due to a user interaction or from a server push), the model proxy sends a "change" notification.  The mediators in the view are registered for these notifications so that they can update their view components.

Whenever the view changes, the mediator sends a notification which a command will handle to update the model.

This seems to cause a notification loop.  For instance, the user makes a change in the view which causes the mediator to send a notification of the change.  That is eventually processed by the proxy who sends a notification of the change.  This notification is then processed by the mediator which originated the first notification.

Since there may be multiple mediators in the view who need to know about the model change, the proxy really does need to send the notification whenever there is a change.  Also, the model can be changed from the server side so notifications seem to be essential.

Is there a good way to prevent this kind of notification loop?  Is this normal?  We also seem to have duplicate command types: one which comes from the view and one which comes from the proxy.

Also, typically, you want the view to represent what is in the model.  However, in this builder-type application, the view often knows about changes before the model.  For example, when an object is resized with a drag, the UI component already knows it's new size before a notification can be sent to the model.  It seems odd to wait to do the resize until the notification is received from the model.

Does anyone have any suggestions on how to handle this situation?  Let me know if I need to explain this better.

Thanks,
Paul

Is it bad practice to require that a view (UI) component implement a particular interface?

We have a framework which is going to be used by multiple applications.  The applications will decorate a base visualization component (table, pie chart, etc) from the framework with menus, etc.  The framework retrieves the decorated component from the application through a proxy which acts as a factory.  Currently, the factory just returns a DisplayObject.

In order for the framework to create the correct type of mediator for the base component, the framework must know what type of base component is being decorated.  (There needs to be a different mediator for a line chart vs a pie chart).

Our idea is to require that the decorated component returned by the factory implement an
interface which returns our base component.  We can then create a mediator based on the type of base component.

Our concern is that this will make the UI component less portable since it now must implement this interface.  Does this seem acceptable or is there a better way to do this?