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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
