I'm liking Frank's idea about makeing a "setup action" super class which would store the url for the setup action. I think that this identification of these "setup actions" would probably be important to a web application in other ways too. It seems that these kind of actions frequently have other "regional" data objects that could be kept in scope for the length of time you are in that region. If you had identified such regions, then one of the things you could do upon entering a region ( hitting a setup action ) would be too clear out all other stuff from session scope that had been related to the previous region.
Is it, however, possible that you could design you application to where all the mapped actions were "setup actions"? I guess not. Basically this is a question of whether we can introduce a hierachy into the actions? Is this a bad thing? Something that should already be handled? --- On Tue 02/14, Frank W. Zammetti < [EMAIL PROTECTED] > wrote: From: Frank W. Zammetti [mailto: [EMAIL PROTECTED] To: user@struts.apache.org Date: Tue, 14 Feb 2006 18:59:11 -0500 Subject: Re: Another struts design question Michael Jouravlev wrote:> On 2/14/06, Rick Reumann <[EMAIL PROTECTED]> wrote:> >> In the action just look for some param like "fromPage" and key off of>> that for your return. (Of course a drawback is you'll need to remember>> to set this var on the pages that need it - of course there are ways you>> could simplify that even, if really necessary).>> >> Using session is much simpler ;-)>> This is one of those times I would agree :)My suggestion would be to have a base Action in which you set a session attribute to tell which page was server. Actually, you would store two, the current and the previous.Here's my concern... let's say you have page A and page B, from which you can go to page C. From page C you want to return to page A or B as appropriate. You could do this a number of ways, but what if you are using the common paradigm of a setup Action for a screen, and then a collection of Actions which really can be though of as event handlers for a given screen (could be a DispatchAction just as well, that wouldn't change anything).If you want to go back to page A from page C, and you got to page C by maybe submitting a form, then the problem is that you got to page C via an event handler in essence. But, when you return to page A, you really want the setup Action to fire again. So, just recording the last request isn't sufficient.If you have a base Action that sets that session attribute, then you can have only your setup Actions extend that base class. Then, when you want to return to the last page from any other page, you look up that value and you now know which SETUP Action you need to call. More precisely, you would look at the second value in session (think of it as a stack) because every time a setup Action is called you really need to push a value on the stack so that the second value on the stack is truly the last page, not the current pages' setup Action.Does that make any sense to anyone but me?? :)Frank> ---------------------------------------------------------------------> To unsubscribe, e-mail: [EMAIL PROTECTED]> For additional commands, e-mail: [EMAIL PROTECTED]>>>>> ---------------------------------------------------------------------To unsubscribe, e-mail: [EMAIL PROTECTED] additional commands, e-mail: [EMAIL PROTECTED] _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
