[cgiapp] handling data and control flow better (longish)

[David N. Blank-Edelman]

Hi Ron:

On Jun 8, 2009, at 8:49 PM, Ron Savage wrote:

> What I'm saying is that I have structured my code so as to avoid this
> 'have to go back' scenario. So, I'm suggesting your code can be
> restructured to avoid it also....
> This makes me think your run modes are linked together much too  
> tightly
> (when you talk about 1 leads to 2 leads to 3). Perhaps this linkage is
> in your head, or perhaps it's built into the code.
>
> When my user selects something on the screen and submits a choice, I
> don't care what the last run mode was [1], and I regard their  
> selection
> as specifying precisely 1 run mode.

Ok, so I think this is entirely possible that I'm doing the wrong  
thing. As I mentioned before, my users have to walk through an N-step  
(or N-page) process to complete the task I need. They presumably could  
provide the input I need in a random order, but I can't see how it  
would help them understand where they are in the process.

An analogous situation would be a shopping cart application where the  
user first enters the billing shipping addresses {next page} the  
payment info {next page} confirms the order. In that case you want  
them to move through each of the steps, in order, and you care about  
making sure that each page is filled out properly before going to the  
next one. I have a similar linkage. Perhaps there's a way to avoid how  
tightly these run modes are linked together for the sequence, but  
being a bear of very little brain, I don't see it.

> o This is no more that what you've said, right? But this situation
> should not be regarded as a problem, it's just how things are. I don't
> see how you can chop any one of those 3 sets of data. Each contributes
> (differently) to the work being done at any point in the lifetime of  
> the
> current run mode.

Agreed. Part of my whine was about how the three sets of data  
contributes differently not only based on the point in the lifetime  
but also how one got into the run mode.

> (a) The user's submitted data is the most transient, i.e. has the
> shortest lifetime. It is not connected with memory in any way [2]. It
> just hits the deck at the beginning of the run mode's lifetime, and  
> the
> run mode must deal with it.

My point was not only must the current mode deal with it, but in  
validation scenarios, sometimes the subsequent or prior run mode must  
also have to deal with it (again). And how you deal with the submitted  
data is impacted by:

  1) the run mode
  2) how you got to the run mode (directly, repeat via validation,  
skipped to this mode from another one)
  3) potentially what you already have in session memory (and/or in  
the database)


> (b) The session data /is/ (medium-term) memory. It ties this current
> instantiation with the previous one and the next one. So it will hold
> just enough data to solve the problem of how to make that tie work for
> the benefit of the user, i.e. so the current run mode's work is
> meaningful.

Right. And perhaps part of my issue is how quickly I should be moving  
things from CGI query-land into C::A::P::Session-land. But the logic  
for what should take precedence at any one time requires a little head- 
scratching.

      -- dNb