DCCCV, or, parts reuse for apps. Software bus.
DCCCV, or, parts reuse for apps. Software bus.
- Subject: DCCCV, or, parts reuse for apps. Software bus.
- From: Michael Gersten <email@hidden>
- Date: Thu, 06 Jun 2002 12:53:28 -0700
[Second part of a post. The first part had some MVC comments, with a table view as the V.]
To understand what I'm about to say: "Model" is really data + data controller.
Data/Input/Output (storage) <--> Data controller <--> App Controller <--> View Controller <--> View/Output/Input (user)
(DCCCV :-)
Only the data controller talks to the data in a well designed app.
Only the view controller talks to the view in a well designed app.
All of the controllers talk to each other.
App controllers might not be reused. The others are.
Data controllers and view controllers do talk to each other. EOF and WOF both are examples, as was (from what I understand) the older DBKit.
Ideally, just as there are common protocols for the data controller that everyone else can use (for example, Key/Value), so too there should be (but currently are not) common protocols for the view controllers.
[Unfortunately, the ViewController side of EOInterface and WOF are not compatible. Code written for one cannot work with the other.]
[[ After a little more reflection, I'd like to throw this idea/discussion to the list for comments:
The view controller/view can be broken down, with real examples, as:
1. The combination of data, table view data source, and table view is a min-MVC. The C in this case is the data source protocol, and is reused as often as the view is reused.
2. The combination of EODisplayGroup, EOInterface's table view/table view column associations, and a table view is another such mini-MVC with reuse.
3. The combinarion of NSArray or WODisplayGroup, the WORepetition and a row template (??? No WOTable dynamic element?), and an HTML output is a third,
4. The interface to the model -- data source protocol, EODisplayGroup, array -- varries between them
5. Some sort of standardized data access system is needed. EOKeyValueCoding turned out to be so useful, and usable on all objects, that it is now NSKeyValueCoding, and part of the base system.
Cox has written about "Software Bus's", like hardware bus's. The ideas of "get data out of the model to show the user" has three different incompatible ideas, and no attempt was made on the newer versions to be compatible with the older ones, nor were the older ones amended to be compatible with the newer. This means that any app that wants to be portable across output system needs to translate these three ideas to a common internal API.
Can there be some way to present an object grouping out of the model that is as generic and as basic as the way that an object is presented out of the model, that it can become as standard as KeyValue? One that permits table views of non-database data, table views of database data, and a web table of either, without having to alter anything in the model or app controller? And, as long as the columns aren't going to change, the view controller's API/Interface also?
[[[A quick glance at the apple doc site shows that 5.1 WOF defines an EOWidgetAssociation abstract class, and two sets of extensions, that looks like Apple is thinking along these lines -- make the view controller and view of a user-IO system as much a user-model as the data controller and data of a data-IO system is the data-model. Is that going to be extended so that cocoa-widgets, swing-widgets, and html-widgets are all identical to a java EOF app?]]]
]]
--
I am a Mac 10-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
_______________________________________________
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.