Hubert Rabago wrote the following on 10/25/2004 11:54 AM:
First, allow the editing of a player from one location only. This way, I only need to get back to that page.
I 'try' to do this also.
Second, if you're on the roster screen, and you want to edit the
player, I'll let you do that, but in a separate window.
I like this approach also and is what I decided to do for this one app (not related to nfl or rosters:). I was initially going to try to avoid the opening of extra windows, but in this case it makes life so much easier.
However, when I absolutely need to support this, then the location to forward back to (ain't that an oxymoron?) gets included as an optional request parameter. If it's present, that's where I forward to after the edit. If it isn't there, I forward to the default "view" page for that data. Just to clarify, the optional parameter isn't a dynamic value that gets calculated into a view. It's a static label, so I still control which views an action forwards to, and I can still see them all in my config file.
Right. The problem/ugly part is having to make sure you set up, in a seeminly unrelated action, all the stuff the action you will forward to also needs to perform its task.
I suppose the difference between this and your session+mapping approach would be, you'd be duplicating info on the config, whereas I'll just have an if statement on my action. In both cases, each "edit" link/button/form would have to be aware of what it's got to do to get back control after the edit operation.
Yup. I only opted for the config approach since later on if you didn't need the 'if' logic, I found it cleaner to just delete the config entry versus having to mess with the action if logic - although like I mentioned above, I'd still have to have my action aware of where it's going to next so I'd still end up having to modify the action if things changed, so the config approach doesn't buy much anyway:)
Thanks for your input. I appreciated it.
-----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED]
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.
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Rick
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
