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]
