Hi Rick,
I did this for a large application where there were a lot of different
record types with various linkages much as your roster has with players,
and where said linkages could nest quite deeply.
You will need to use the session to do it cleanly. The idea is to
somehow keep a stack of ActionForms.
Another need I had was to allow several such page-flows to go on
simultaneusly in multiple windows (which session scoped forms would have
problems with).
In my case I went so far as to implement a new scope - the 'operation
context' - which is basically a sort of sub-session identified with a
unique id which is its attribute key in the session, passed in the
request url. It consists of a map and some other properties and methods.
I overrode the request processor to allow for my actionForms to be
stored in this context.
I also needed to bang up a fair bit of support code to deal with things
like cleaning up the operation contexts at the appropriate time etc...
The operation contexts can be stacked, and the term I came up with to
describe the act of putting aside the current one to go work on another
with the ability to come back later was "diversion", so when the user
"diverts" to another page the dispatch action will note that they are
diverting to X (based on some hidden field set when the user clicks the
link or button to divert) , will push a new operation context onto the
stack for that operation context id, and forward to the appropriate
action (for which the requestProcessor will instantiate the new form
and store it in the operation context as normal). When the user has
finished playing with X (ie they save the changes or cancel) the action
will pop that operationContext replacing the previous one at the top of
the stack and a url or forward name or such like stored as a property in
that operation context tells it which action to go back to after that to
continue where the user left off. Obviously since your using a stack you
can divert multiple levels as deep as you want...
Since the operation context has its own attributes (lie session and
request) one can also use these to pass info between the actions and
then do a redirecting forward (where the operation id is encoded as a
url parameter).
The application I did this for is quite complex and has a lot of
configuration that can be done through the ui. There are many different
record types that the administrator can create and edit, and most have
relationships to various other records (that have their own dependencies
ad infinitum...) that would normally have to be created first, making
the process quite tedious. By implementing 'diversions' however I was
able to make the application practically guide the admin users through
the process almost like a wizard but much much more flexible. Since
there arent all that many admin users for any particluar deployment of
the app, the memory overhead for using the session like this wasnt
significant, while the huge boost in user-friendliness was. :-)
In your case you probably dont need to go as far as I did. You could
perhaps just keep track of the pages in the stack in a session scoped
collection and override the requestProcessor to look in that collection
for the form instead of instantiating it. If it finds a form in that
collection it can use that (storing it under the normal key in the
session (or even request actually. Hmm) where the other strust things
(like tags) will look. (You will note we need to go via an action rather
than hitting any JSPs directly here so that we make a trip through the
requestProcessor where our code will find the form and put it in the
appropriate place!)
hth
Andrew
Rick Reumann wrote:
> To cut to the chase.. Imagine a hypothetical UI where you have
> checkboxes next to football players and by checking the boxes and
> hitting 'save' you would be saving a roster. Typically you'd have a
> FormBean to capture this information and probably a "RosterAction".
>
> Now also imagine that next to each player on the above list where you
> set up the roster, there is also an 'edit' button that lets you edit the
> player. In the application this will not be the only way you can get to
> edit a player so its behavior needs to be self contained (ie
> "PlayerAction").
>
> The question I have is, how do you guys handle situations where you need
> to get 'back' to different pages depending on where the user was? For
> example, in the above scenario, after a user edits a player, I want the
> user to be forwarded "back" to the same roster selection screen with
> what he was working on - what he's checked - still selected. However, if
> maybe the user is getting to the edit a player functionality from a
> search screen of search results where he searched for a player to edit,
> I want the user returned to that screen.
>
> The only clean way sort of clean way I've found to accomplish this is to
> rely heavily on the use of Session. For example if the Session is used
> to store search results and the roster. You can have mappings that look
> like:
>
> <action path="/playerActionFromRosterScreen"
> ....
> <forward name="success"
> path="/WEB-INF/roster.jsp"/>
>
> <action path="/playerActionFromSearchScreen"
> ....
> <forward name="success"
> path="/WEB-INF/search.jsp"/>
>
> If you don't use the Session above, all have to make use of fowarding
> back to other actions and having to set up a bucnh of parameters before
> doing so. The maintenance of this gets to be a pain. I'm curious of how
> others handle these situations.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
|