Re: flow of control for sequential data processing

FROM : Ricky Sharp
DATE : Mon Feb 18 22:31:30 2008

On Feb 18, 2008, at 1:01 PM, Daniel Child wrote:

> 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.



I would create another (fourth) "master" controller.  It's job would 
be to manage what step is currently loaded as well as to manage 
parameters/results between them.  This master controller could even 
be your application controller itself.  And, if parameters/results 
need to be passed around from step to step, consider using a dictionary.

In my kiosk-style app, I do this quite often where my app controller 
loads a particular screen for the user to interact with.  Some screens 
are "pushed" onto a stack and I thus have multiple controllers in 
memory.  But, for the most part, stack just has a single entry; 
allowing me to effectively swap out controllers one at a time.  I then 
created a single header with extern NSStrings to represent the keys 
into the "parameter" dictionary passed from screen to screen.

___________________________________________________________
Ricky A. Sharp        mailto:<email_removed>
Instant Interactive(tm)  http://www.instantinteractive.com