Re: dual controllers
Re: dual controllers
- Subject: Re: dual controllers
- From: Keith Ray <email@hidden>
- Date: Mon, 14 Oct 2002 12:41:10 -0700
On Sunday, October 13, 2002, at 03:07 PM, Brian E. Howard wrote:
On Sunday, October 13, 2002, at 04:35 PM, Nicholas Riley wrote:
On Sun, Oct 13, 2002 at 11:33:56AM -0700, Keith Ray wrote:
One or more Smalltalk environments (VisualWorks), have the concept of
"ValueModel" objects,<snip>
The above refers to ST/X but it's pretty close to VW usage. <big snip>
All this talk of Smalltalk and such is fine and dandy, but it helps me
not in the least, or anyone else here who is trying to do COCOA.
If you can't learn from the best... you refuse to learn?
Sorry. I'm sure I would also be frustrated if I were in your shoes.
[...] But I got to ask: if it isn't doable, why is the idea mentioned
in so many places?
Like AppleScript recordability, it's a good idea that isn't often
implemented. [MacOS 9 Finder was one of the few recordable apps around.
If you haven't ever worked with recordable apps before, try booting up
in MacOS9, run the script editor, hit 'record', and do stuff in the
finder.]
Perhaps the book authors on this mailing list can explain why the
examples in their books so often merge the view/controller/model into
the same class in their examples? (I assume many do it to keep their
code as "simple" as possible -- concentrating on showing how to use the
GUI framework.)
Let's start with the basics - model/view/controller is based on the
Observer pattern: the views should be observers of the model.
As an example of this pattern, let's pretend that an NSSlider and two
read-only numeric text boxes in a window would each be an observer of a
model object.
+-------------------------------+
| (====()===================) | pretend XX and YY are separate
| copying byte XX of YY bytes | read-only text fields
+-------------------------------+
When the model object changes (we've made some progress in copying a
file, for example), it tells all of its observers that something
changed. According to the classic Observer(Model-View) pattern, each of
the observers then asks its model for whatever data that observer is
interested in. In the case of the slider, it is interested in the
beginning and end-points of range, and the current value within that
range. In the case of the numeric text boxes, we would want one of them
to fetch and display the end point of the range, another to fetch and
display the current value within that range.
Now I'm still learning Cocoa, so I can't tell you how to implement this
yet. It seems like Cocoa widgets do not have the concepts of "model"
and "observer", or at least I haven't seen those terms used in
documentation yet... NSNotificationCenter seems to be way to implement
observers/observable objects, and that framework might be flexible
enough so you could set up model objects to PUSH information to
observers in a single step, instead of having a push-notification step
followed by a pull-fetch step.
As another example, let's look at NSTableView.
NSTableView seems to require its model object to implement three
methods:
numberOfRowsInTableView // 'get' value
tableView:objectValueForTableColumn:row: // 'get' value
tableView:setObjectValue:forTableColumn:row: // 'set' value
Hillegass puts these methods into the MyDocument class in his book
(RaiseMan example, chapter 5-ish.)
I would have put them into an EmployeeTable class, and have MyDocument
own an instance of that class.
But the problem is that NSTableView is not set up to be responding to
notification events ("hey, I've got new data!") from the model object.
(We could set up MyDocument to be responding to notification events
from the model, and maybe Hillegas does that later in the book.)
Suppose the app was scriptable, and someone could set the values of the
employee table from using AppleEvents -- we would want to the model to
notify its observers, and as a result, the NSTableView updates itself.
Or suppose all of the multiple windows in the RaiseMan example
referenced the same model object -- changing a cell from any window
should make all of the windows update with the new cell. This would be
easy to implement if the Observer Pattern (model/view) was implemented
in the widgets.
Hillegass has an "updateUI" method in MyDocument and I cringed when I
saw it -- I've had to do similar things when I have written GUI code
that didn't have help from the Observer pattern, and it causes problems
for maintainability (which is why Smalltalkers have had the Observer
pattern to help them code UIs since the early 1980's).
All I can do is use notifications and delegates to the max and
whatever still ends up where it should not belong is an "exception
that proves the rule?"
Not sure what you mean by this... notifications are a necessary part of
the Observer pattern that Model/View/Controller is based on, and SOME
of what Cocoa seems to use delegates for seems to be for referencing
model objects.
----
C. Keith Ray
<
http://homepage.mac.com/keithray/xpminifaq.html>
<
http://homepage.mac.com/keithray/resume.html>
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.