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