re: dual controllers

FROM : Keith Ray
DATE : Sun Oct 13 20:33:56 2002

> [...]
> I am trying to decouple as much of my program as possible and 
> separating model and view logic into different controllers seems like 
> a good idea, but I have not been able to figure out how to do it, or 
> find any discussion on the topic.  Perhaps it is so simple that no one 
> has bothered to explain it.  For a smart guy I can be awfully dense at 
> times.
>
> Brian E. Howard
>

This actually is a difficult subject, and one that isn't well-described 
in how it relates to commonly used frameworks like Cocoa, PowerPlant, 
and MFC. I haven't yet seen many good discussions in books, though 
there are several books on my to-read pile that might have them.

One or more Smalltalk environments (VisualWorks), have the concept of 
"ValueModel" objects, which can decouple a model from a view at very 
low levels (for example, a one button "view" can be linked by an 
ValueModel Adapter to a single boolean variable in your model.) There 
seem to be docs at 
<http://www.exept.de/exept_99/onlineDoc/english/programming/
vmodels.html>.

Because of Objective-C's relationship to Smalltalk, it theoretically 
would be very easy to port this ValueModel concept to Cocoa (it might 
require extending via subclasses or class categories all of the current 
widget objects to add some of the necessary features).  With 
considerable difficulty, this concept has been ported to Java and 
called "XMLTalk" 
<http://www.trcinc.com/knowledge/software/xmltalk/xmltalk.asp>.

It is also an interesting "lack" that the book "Design Patterns" by 
Gamma, et al., doesn't have the ModelViewController pattern as one of 
its patterns... perhaps because of their rule that a pattern had to be 
found in three independently-developed pieces of software to qualify 
for inclusion in the book. The original Smalltalk "controller" is now 
built into our operating systems -- the thing that listens for events 
and routes them to the correct widgets -- so ValueModel may be more 
helpful as a design pattern.

Another way to get your domain/model classes separate from the GUI 
classes is to write them test-first (aka TestDrivenDevelopment/TDD, 
TestDrivenDesign). A book on this subject is at 
<http://www.amazon.com/exec/obidos/ASIN/0321146530/qid%3D1034532395/
sr%3D11-1/ref%3Dsr%5F11%5F1/103-3841993-4871027>. There are two 
objective-C frameworks for doing TDD mentioned here 
<http://www.xprogramming.com/software.htm>.

--
C. Keith Ray
<http://homepage.mac.com/keithray/xpminifaq.html>
<http://homepage.mac.com/keithray/resume.html>
_______________________________________________
cocoa-dev mailing list | <email_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.