Archive for the 'Smalltalk' Category

MVC: A brief history of Models, Views and Controllers

Saturday, January 31st, 2009

Any web-developer Rubyist knows about models, views and controllers. The MVC paradigm is embedded in the structure of Rails and Merb and encouraged by Ramaze and Sinatra. If you’re a Mac developer or an iPhone bod then MVC is common practice there as well. Same goes for Sproutcore and even Microsoft is getting in on the act.

But where does MVC come from?

Well, like most things I enjoy in the world of software development, MVC has its roots in Smalltalk. However, things used to look slightly different to the MVC we know and love. In Smalltalk, the basic Object has a feature known as “dependencies” built-in; nowadays, we would call this the observer pattern. Basically, any object can register an interest in any other object and will be notified whenever the target changes.


target addDependent: listener.

Later, when something changes within target, it can decide to notify all its dependents (observers):


self changed: #SomeArbitraryMessage.

and the listener has its update: aSymbol method called.

Building this notification mechanism right into the core of the system means that it can be used everywhere – especially when designing user-interfaces (remember, Smalltalk was the GUI for the Xerox Star, which his Steveness bought and adapted for the Lisa). Models were the system components, the pieces of the system that actually do the work. Views represented portions of the screen and controllers represented the keyboard and the mouse. These parts were arranged as follows:

MVC in Smalltalk

MVC in Smalltalk

The view would add itself as a dependent to the model and display the relevant aspects of the model on-screen. The user would see this, manipulate it via the mouse and keyboard, which triggers the controller. The controller sends messages to the model, which triggers its notifications, prompting the dependent view to redraw itself. In other words, the controller and view are independent objects that know nothing about each other – the only tie between them is the controller’s knowledge of the model and the dependency mechanism.

Contrast this to the MVC we know today:

MVC in Rails

MVC in Rails

Here the user pokes the controller, which in turn sends messages to the model. The model does its thing and then the controller extracts the relevant information and passes it to the view, which is then rendered to the user. In this manner, the controller lives up to its name, orchestrating the entire cycle – and is the centre of all the coupling (as it knows about the view and the model).

So why did things change (first in Smalltalk and then the following MVC frameworks)?

The first problem is that the controller takes input and the view handles output – as separate objects. Which, especially for desktop applications, doesn’t really work; if you click on a text-field you expect different behaviour to clicking on a scrollbar.

Secondly, imagine an array of models being shown in a list box. The list box has the concept of a current selection. So your array model (a model of models) needs to have a current selection, so that the view knows which is which. But what if the same list is rendered in two places at the same time. If you point both views at the same array model, they would both share the same selection properties. So you actually end up with something more like:

Getting Complicated

Getting Complicated

As you can see it gets nasty pretty quickly. And actually the controller is simply passing its messages directly through to the array model which is actually doing the routing of the other messages – the controller is pretty much redundant.

So if you swap things around, merge the controller and array model (into some sort of array controller) and then add multiple array controllers – one per view – to deal with the selection issue, suddenly you have the newer style object layout. Requests go into one of the controllers, it routes it to the model, then parcels up the results and invokes the view.

Evolution in action.

Loading the MySQL drivers into GNU Smalltalk

Friday, November 14th, 2008

It’s an unfortunate fact that many Open Source projects have documentation that is sadly lacking. A case in point is GNU Smalltalk.

Smalltalk is one of my favourite languages but a decent Smalltalk implementation that fits with your native window manager is hard to find. The point of GNU Smalltalk is that it works “headlessly” (Smalltalk invented the graphical user-interface and the integrated development environment so this is quite a departure), so I can still use my favourite text editor and run stuff from the command line. Just like Ruby!

However, it’s taken me a couple of hours to figure out how to simply connect to a database. But now I have, here it is:

  • Install GNU Smalltalk (in my case using MacPorts):
    sudo port install gst
  • Start GNU Smalltalk and create a working image:
    cd /Users/rahoulb/source/st
    gst
    st> ObjectMemory snapshot: 'work.im'.
  • Ctrl-D to exit Smalltalk and then restart using your new image:
    gst -I work.im
  • Load the DBI database driver:
    st> PackageLoader fileInPackage: 'DBI'.
    Load the MySQL driver:
    st> PackageLoader fileInPackage: 'DBD-MySQL'.
    Save your image so you don’t need to reload these packages again:
    st> ObjectMemory snapshot.
  • Open a connection to your database:
    st>con:= DBI.Connection connect: 'dbi:MySQL:dbname=mydatabase' user: 'myuser' password: 'mypassword'.
    Grab some data:
    st>results:= con select: 'select name from customers limit 10;'
  • Bask in the glory of your data