MVC

Jamoma implements a Model-View-Controller (MVC) architecture for working in Max.  More information on this design patter can be found at http://en.wikipedia.org/wiki/Model-view-controller, or in various Ruby on Rails or Apple Developer texts as well.

Components

In Jamoma, the components of the MVC pattern can be summarized as follows:

• The model is the 'algorithm'.  This is the core entity of any given module, which is responsible for performing the required task.
• The view is the user interface.  However, the term 'user interface' here means any way with which a user interfaces with a module.  This may be a graphical user interface, a remote Open Sound Control interface, or some other method of interacting with a module.  A collection of objects may make up the view, including standard Max objects, the jcom.ui object etc. 
  The jcom.ui object is also a 'glue' object, in that it acts as a bridge between the UI and the controller.
• The controller is the state-management system.  It is a layer in the module that binds any of the various 'views' to the underlying algorithm, and manages the workings of the (stateless) algorithm.
  

Ambiguities

There are several ambiguities in Jamoma's implementation of the MVC pattern. 

The most obvious ambiguity is in the separation of the controller and the view.  This stems, in large part, from the fact that Max does not separate the UI from the underlying processes.  Thus, to provide this architecture, some objects are required to bridge across the view and the controller in order to tie them together such that they work.

One such case is the attribute for determining a module's size.  In a utopian world, a module would not need to know anything about the size of it's view.  Thus the module would have attributes pertaining to function, and the view might have it's own attributes, such as the view size.

In it's current implementation (Jamoma 0.5 dev) it is perhaps more ambiguous than it need be.  We also include a number of parameters inside of the UI.  They should really be in the hub and communicated to the UI, but that makes the code messy and there are other important things to do...