On Wed, February 15, 2006 4:24 am, Mark Lowe said: > My understanding of the suggestion is like replicating the history > object in client side javascript. Which does sound like a good > suggestion.
That's a good way to put it :) The only difference is that you wouldn't build up a whole history, although I suppose you could if you wanted a breadcrumb-type thing. Instead, always have a two-element history stack, so to speak, probably as simple as two session attributes, something like currentURI and previousURI. When you hit an Action, you do: previousURI = currentURI currentURI = thisURI And like I said, only do this from Actions you would want to return to, i.e., setup Actions... don't do it for an Action that is the target of a form submission for instance because most likely the forward from that will (a) be to the same page (think of an "add item to list" kind of function) or (b) be to a new page. If it's (a), you wouldn't want to change the values in session because they would be correct already and would be made incorrect by changing them (because previousURI and currentURI would become the same), and if it's (b) you would want to change them so that the current page becomes the previousURI and the new page is currentURI so that your "history" remains intact as expected. Of course, you wouldn't have to do this as a custom Action, you could just as easily have a helper function that you only call from the appropriate Actions. I'd probably do that myself, although then it isn't quite "automatic" as it would be (seemingly) with a custom Action. Also, this implies that *everything* goes through an Action in your app, which is a Struts best practice anyway. If you ever jump directly to JSPs, your history won't work as expected. Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
