Skip navigation.
 
mlflow of control for sequential data processing
FROM : Daniel Child
DATE : Mon Feb 18 20:01:14 2008

A while ago, with much help from the community, I set up a test app 
with a central controller and various peripheral window controllers. 
The central controller kept references to the other window 
controllers, and loaded each only when needed. The window controllers 
could in turn communicate back to the central controller using the 
fact that it was the NSApp's delegate. That worked fine for that 
particular application since the flow of work logically centered 
around a central location.

But now I have a different scenario.

I want the user to perform a series of tasks on some data in a 
particular order, and each task has associated with it a controller 
and a model to handle the persistent data. Something like:

[Controller A / Model A / perform step 1 tasks] followed by
[Controller B / Model B / use results of step 1 to perform step 2 
tasks] followed by
[Controller C / Model C / use results of step 2 to perform step 3 
tasks] etc.

where each controller is associated with its own interface and with a 
certain data model layer. The data is being processed in each step, 
and is then passed along to the next step for further processing. 
Thus, for instance, once you have done the first step, there is no 
reason to return to the interface provided by Controller A.

In each controller, I have been setting up references to the 
controller used in the following stage, and then sending data long 
with it. But I think this is going to be a problem in terms of 
memory. If Controller A has an instance variable of type Controller 
B, then if you "load" Controller B for it to do stuff, that loading 
is done from within the context of A. How do you release A? If you 
load B from A (B being an instance variable of A), then releasing A 
is problematic because you are within the context of A.

I feel I'm stuck with a choice between a continual memory buildup or 
circular references. And the way I keep passing bits of the model 
around from one controlller to the next makes me think that the 
design is flawed....something monstrous dish that resembles a cross 
between lasagna and spaghetti.

Is there a better way to handle this kind of sequential data 
processing from a design standpoint? Thanks.

Related mailsAuthorDate
mlflow of control for sequential data processing Daniel Child Feb 18, 20:01
mlRe: flow of control for sequential data processing Ricky Sharp Feb 18, 22:31
mlRe: flow of control for sequential data processing Daniel Child Feb 19, 02:49
mlRe: flow of control for sequential data processing Charles Steinman Feb 19, 03:07
mlRe: flow of control for sequential data processing Daniel Child Feb 19, 03:28