Last updated at 4:09 pm UTC on 14 January 2006
Old MVC vs. Pluggable MVC and Pluggable Morphic
MVC means Model-View-Controller.
"Pluggable" means that a widget may be "plugged" onto a "model" object and configured to work with it.
Consider the four panes across the top of the browser. In old MVC, there are three parts:
- A Model: The thing being manipulated. It is an instance of class Browser.
- A View: This displays the list of things in the pane.
- A Controller: This responds to user input (clicks) and tells the view and model what to do.
The browser has four messages that it wants sent to it, one for a user click in each of the four lists in the broswer. selectSystemCategory: n for the first pane, selectClass: n for the second, etc.
In old MVC, the controller tells the view where the click occurs. The view figures out which item in its list that is (don't forget: it is scrolled), and sends (model selectSystemCategory: n). A method in the class of the view must send this. The view next door sends (model selectClass: n) instead. So, they must be different classes with different versions of the method that sends that. BrowserSystemListView, BrowserClassListView, etc.; 25 of them for the 25 kinds of panes in the system, and 25 controller classes.
In Pluggable MVC, which was installed in April, there is only one ListView class. It has a variable that holds what message to send to the model. actionSelector has the value #selectSystemCategory: in the instance for one pane, and #selectClass: in the instance that owns the other pane. Neat, simple, and parameterized. We use perform:with: to send the actual message (model perform: actionSelector with: n). This is a way to order a certain message to be sent, when you don't know the name of the message at code writing time.
It is really a little more complex when you realize that each pane has its own menu. So we had to define a lot of messages in Browser to build each of those menus. The View has another variable that is the name of the message to send to the model to get the menu. The view then saves the menu.
The browser has an initialize method that creates the views and hands them all the selectors to remember. The view turns around and sends that selector to the browser to get what it needs for its specific pane.
See also Forms, Views, and Windows