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
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
