I've recently written some code that addresses what sounds like the same
problem - maintaining the stae of several screens until the user "commits" a
transaction.
There's one gotcha I'm aware of that I don't think is covered by the design
you describe here. The user can open a new browser using File/New/Window
(in IE) that shares the same session as the origional browser. If the user
has two browsers open that share the same session, wouldn't it be possible
for one Screen stack to effectively step on the other one?
I've partially solved this problem in my code using the concept of a
"module." Each set of connected screens stores it's working set of data in
its own module, so the user can be doing something different in one browser
without stepping on the state information of the other. This still doesn't
solve the problem completely though, in the case where the user is doing
concurrent identical tasks in each browser. I think I can solve that
problem by attaching some sort of "transaction id" to each independent
context using a hidden form field or by doing a URL fixup, but I haven't
tried that yet.
Does this help at all? If anyone is interested I could post more details on
what I've done so far. The code itself is really raw right now, and overall
not nearly as elegant as the stacking idea.
-Jon
----- Original Message -----
From: "Sean Legassick" <[EMAIL PROTECTED]>
To: "Turbine" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, June 30, 2000 6:09 PM
Subject: Re: Screen stacking (long)
> On Fri, Jun 30, 2000 at 12:11:26PM -0700, Daniel L. Rall wrote:
> > It's--obviously--always been stack-based, but the specifics of the
> > implementation has varied based on the application framework. One
> > trouble spot that I've noticed in the past occurs when the user finds a
> > way to bypass the screen-stack entirely. This was probably just due to
> > a inadequate implementation, however.
>
> Yeah this was one of the gnarly things.
>
> > If you like, I'd be happy to take
> > a look at your API--just fire it over to me directly whenever you feel
> > it's ready for show and tell. :)
>
> Cool, cheers Daniel. I'd certainly welcome your feedback.
>
> I though though that I might as well post to the list as well, unless
> anyone objects to the noise :-)
>
> ----
>
> The basis of the mechanism I have in mind is two classes, ScreenState and
> ScreenStack.
>
> An instance of ScreenState holds all necessary data to restore a screen's
> state, including any/all of screen class name, template name, request
> parameters, a WebContext and objects to put in the user's temporary
> hashtable when the state is restored.
>
> The ScreenStack is, as its name suggests, a stack of these
> ScreenState objects. A ScreenStack instance is kept in the TurbineUser's
> temporary hashtable (as per Jon's comment over in scarab-dev). For
> convenience I'd like it to be accessible through a getScreenStack method
> on RunData, but this could be hung off User instead...(?)
>
> It will be possible to construct a ScreenState manually and push it on
> the stack, and I also plan to provide convenience methods on ScreenStack
> to do this for you based on the state represented by the current RunData
> object.
>
> So you could write (say in an Action which is going to switch over to
> another screen but wants the user to return to the EditUser screen when
> they've finished with the next screen):
>
> ScreenState state = new ScreenState()
> .setScreen("EditUser")
> .setParameters(data.getParameters());
> data.getScreenStack().push(state);
>
> or you could write inside the Screen itself (the 'true' means include
> all request parameters):
>
> data.getScreenStack().pushCurrentState(true);
>
> or to keep the WebContext too:
>
> data.getScreenStack().pushCurrentState(true, context);
>
> and then in an Action later (like the 'cancel' or 'ok' button actions)
>
> data.getScreenStack().popAndRestore();
>
> which causes the topmost screen state on the stack to be restored into
> all the relevant parts of the RunData object.
>
> or to just throw away the top state (because we're not going somewhere
> else after all):
>
> date.getScreenStack().pop();
>
> ------
>
> I'm fairly happy with all that, although of course I'd welcome
> comments/improvements.
>
> Some areas where I'm less confident are:
>
> 1) As you hint at above, there is an issue with links that take you out
> of the current interaction context, such that whatever is one the stack
> right now doesn't every get popped. This is perfectly valid, general
> navigation links will do this as they act as a kind of escape out of
> the sequence of screens the user is interacting with right now.
>
> What I have in mind at the moment is to provide a standard Action
> 'ResetStack' which can be set on any link that acts as such an 'escape'.
> This seems a bit gnarly though (although as such links are most likely to
> appear in navigation screens/templates, it's not _so_ bad).
>
> 2) Sometimes it would be nice to have known what the state of the screen
> just gone was. For instance with an app like Scarab or Jyve every page
> has a Login button. It would be nice if each screen stashed its state in
> the session so if Login gets pressed that state can be pushed onto the
> stack without the Login action knowing which screen was last).
>
> For this I did think about having some notion of a 'last' screen state
> that could be saved and restored through an API very similar to the
> ScreenStack one. Then any Screen that would have a button like 'Login'
> on it would save its state as the 'last' state before rendering back to
> browser. I felt this was getting a bitt tooconfusing though...(?)
>
> (something like data.getScreenStack().saveAsLastState() and
> data.getScreenStack().pushLastState() )
>
> ----
>
> So thoughts? I've coded some of this up already, but wanted to think
> about it some more and get feedback before continuing.
>
> (PS Sorry if what I've written is too abstract, I can write up some
> specific use scenarios as well if it's too hard to follow what I have in
> mind...)
>
> --
> Sean Legassick
> [EMAIL PROTECTED]
> homo sum: humani nihil a me alienum puto
>
>
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
>
>
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
