Re: NSTableView philosophy question.. (MVC Pattern) where to putthe dataSource delegate?
Re: NSTableView philosophy question.. (MVC Pattern) where to putthe dataSource delegate?
- Subject: Re: NSTableView philosophy question.. (MVC Pattern) where to putthe dataSource delegate?
- From: Michael Gersten <email@hidden>
- Date: Thu, 11 Jul 2002 16:12:27 -0700
I'd say: It depends.
To me, a table view data source is either a model level (data controller), or a view level (output controller).
[ This is an important distinction between MVC, which says that there is one controller (the application) mediating between model and view, and my idea of DCCCO, or data + data controller (the model), output + output controller (the view), and app controller in the middle ]
Is there an output-independent way for you to describe your data to any interested object? If so, that goes into the data controller.
Is there anything left over to do? That goes into the view controller.
Should any of it go into the app controller? Possibly. An app controller might want to say "Flag this item", or "Group these items". Then, it has to get data from the data controller, mark it, and then the output controller has to massage it into whatever form that particular output wants. Ex: One output system might do grouping by changing the background color, another by a line between the groups, etc. Another might have no way to display grouping, and the work by the app controller is for naught.
Think "Software bus". A bus's job is to move data between controllers. What is the data transfer protocol part of your API?
Or, think of class(es) [ EOTableViewAssociation, IIRC ] that works with a database layer, that translates between what the database layer (data controller, or model) outputs and what the table view (output controller, or view) wants as input. The translation is a second data controller (producing an I/O independent representation of the data), yet it also has a part that knows how to work with the table view specifically. This is a second output controller -- the tableview itself has a simple output controller designed to work with a data source (data controller).
Why do I think that MVC fails badly in this case? Because you didn't need anything in your app to make it work -- all the default interaction happened between the data controller (model) and the output controller (view), while MVC says M and V never talk to each other.
email@hidden wrote:
>
>
I have a nice little doc app with a pretty decent MVC pattern I think..
>
I have a NSDocument sub-class to handle the document level stuff, a
>
NSWindowController to handle the UI interface,
>
and even a DocumentSettings type class for the data model (i.e. right
>
from the Vermont Recipes stuff!)
>
>
Anyway, I just added a table view and was wondering where is the
>
"appropriate" place to put the
>
NSTableView dataSource delegation methods?? My first inkling is the
>
appropriate NSWindowController sub-class
>
but I also was thinking maybe the NSDocument sub-class??
>
>
Just want to keep a clean paradigm here so was wondering what the "Best
>
Practices" method is for this pattern..
>
>
TIA!
>
>
-Steve
>
_______________________________________________
>
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.
--
I am a Mac OS X-Cocoa/WOF/EOF developer, and I'm available for hire. Please contact me at michael-job @ stb.nccom.com if interested. Resume at
http://resumes.dice.com/keybounce
x
_______________________________________________
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.