On Mon, Jul 24, 2000 at 06:30:51PM -0700, Daniel L. Rall wrote:
> Sean Legassick wrote:
> > 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):
>
> Default should be true.
Agreed.
> > 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):
> >
> > data.getScreenStack().pop();
>
> Good, I like having the option of doing either. I'm not sure how I feel
> about having the ScreenStack actually be the mechanism which controls
> which screen is currently being viewed...is there another entity whose
> job that is that ScreenStack can pop a ScreenState object to?
The actual implementation is that a ScreenState object has a
restore(RunData data) method - ScreenStack is just using that. Does this
address your concern? It would be more explicit without the
popAndRestore convenience method:
data.getScreenStack().pop().restore(data);
?
> > 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 ever 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).
>
> Call me sick, but I tend to think of this Screen stacking idea as
> analogous to a Microsoft "wizard" (or any software that guides its user
> through a series of steps). The "Next" button results in a push(), the
> "Previous" in a pop(), the "Exit" in a clear() (what you called
> ResetStack). Additionally, peek() is sometimes useful to indicate to
> the user what step is coming next.
I think like a stack of modal dialogs layered on top of each other, but
the analogy is pretty similar. In fact I think the wizard is better
because you can escape out of a whole wizard at any point...
>
> > 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() )
>
> I'm not sure if I follow this. Are you proposing a mechanism that
> allows one to insert a ScreenState at an arbitrary position in the
> ScreenStack (such as at the bottom)?
No - but I think you answered my question about it getting too confusing
:-)
> Overall, I like the API. Unfortunately, some things are just hard to do
> cleanly with web UIs. Regardless, I think that a Screen stacking API
> like this one would add value to Turbine.
Thanks. I've already written half this code, and I should finally have
some time for Turbine stuff this weekend, so I'll look at this as well
as seeing how I can help with the state of flux.
> p.s. Sorry I took so long to get back to you on this Sean.
No problem, thanks for the feedback
--
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]
