[comp.lang.smalltalk] An attack on MVC

colin@pdn.UUCP (Colin Kendall) (01/15/88)

I remember a few years ago when I was first learning about Smalltalk
that someone cautioned that the MVC way of doing things was
experimental, and might not be the best way. I agreed, and today
I agree even more. However, it's one of those things that seems
to have become institutionalized just because it's there and 
people try it and it seems to work and...

One of the worst things about it is that the model generally has
no knowledge of its controller(s). At first this sounds like
a good idea, so that the model can be viewed and controlled 
independently by several entities. But the first kluge associated
with this is the famous comment in yellowButtonActivity:

	"Editing to self, rest to model"

Consider this: 
	We recently installed ParcPlace's VI 2.2, and I was
delighted by the enhancement which allows you to paste any of the
last few cut items, by holding down the left shift key when picking
paste. But I HATE left shift kluges, so I decided to allow the
selection of the item to cut by sliding off paste to the right and
picking one from a submenu.

I wanted to do this first for the browser. The menu for the 
CodeView is built by the model (a Browser) at class initialization. 
Since the model never has any idea of what the last few selections
are, I arranged for the menu of cut items to be provided dynamically
by the controller at slide-off time, just as is done for the
vanilla left shift kluge. The controller then performs
#performPasteAction: with the selected cut item. 

The problem was with the default, i.e., the thing to paste if
no sliding occurs. I ended up using #CurrentSelection for the
default, and had to modify ParagraphEditor>performPasteAction:
to use CurrentSelection if the argument was #CurrentSelection.

I could have added more code to have the default provided 
dynamically, but by this time I was frustrated.

I also had to update localMenuItem: for TextController, and
would have had to do so for each of the various controllers allowing
the paste function.

The whole problem would have been simplified if the model had
been integrated with its controller, and hence had had an
awareness of the current control environment. I can think of
some arguments against this, and I can also think of responses
to those arguments.


-- 
Colin Kendall				Paradyne Corporation
{gatech,akgua}!usfvax2!pdn!colin	Mail stop LF-207
Phone: (813) 530-8697			8550 Ulmerton Road, PO Box 2826
					Largo, FL  33294-2826

johnt@mmintl.UUCP (John Tangney) (01/19/88)

In article <2047@pdn.UUCP> colin@pdn.UUCP (Colin Kendall) writes:
 [details deleted]

>The whole problem would have been simplified if the model had
>been integrated with its controller, and hence had had an
>awareness of the current control environment. I can think of
>some arguments against this, and I can also think of responses
>to those arguments.

I am unable to give as detailed an account of where we ran into a similar
situation, but I can vouch for the conclusion:  Integration of the
controller and the model. 

Now, it seems that there are some other paradigms out there which replace
the MVC (or should that be V(MC)?) model.  The MacApp approach is one, and
one which I intend finding out more about.  Does anyone have any other
models in mind?  Would you mind sharing it with us, and we (as the OOP
community) can go about agreeing on and adopting a new standard.

johnt