Sean Legassick wrote:
> [snip]
>
> 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):
Default should be true.
> 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?
> 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.
> 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)?
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.
p.s. Sorry I took so long to get back to you on this Sean.
--
Daniel Rall <[EMAIL PROTECTED]>
http://collab.net/ | open source | do the right thing
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
