Re: Another struts design question
On 2/15/06, Lixin Chu [EMAIL PROTECTED] wrote: ok, I let page A or B pass a returnURL to page C who keeps it in the session scoped actionForm. I think what's being suggested is storing a reference to the referer in the session, and thus circumventing any potential issues with the Referer header being removed in some mystorious way. Not scoping an action form to session to achieve this.. My understanding of the suggestion is like replicating the history object in client side javascript. Which does sound like a good suggestion. Another suggestion could be to pass the returnUrl as a parameter input type=text name=returnUrl value=[EL or scriptlet to getRequestURI()] / String returnUrl = request.getParameter(retrunUrl); returnUrl = returnUrl.replaceFirst(request.getContextPath(),); return new ActionForward(returnUrl,true); Mark On 2/15/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
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]
Re: Another struts design question
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]
Re: Another struts design question
On Wed, February 15, 2006 2:46 pm, [EMAIL PROTECTED] said: 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? I guess the question to ask is what are the kinds of Actions... I don't mean DispatchAction vs. Action vs. whateve else, but the *purpose* of the Action. I can only see: * Setup Action, called when any page is first displayed * Event Handler Action, called most usually in response to a form submission. There is really two sub-types to this, one where the resultant forward returns you to the same page, and one where it brings you to another page. When you go to another page, the question is, do you forward directly to a JSP (I'd bet most people do... I know I do that most often) or does it go to another Action, which is the setup Action for the next page? Some people may refer to that as action chaining, but I don't think it is. If you always forward to another Action, instead of directly to JSPs, what your rally doing is creating almost a prerender phase to the next page. You also are giving yourself the opportunity to have more information, not to mention control, over what goes on. In that way, I suppose you *could* create an app that was nothing but setup actions... that would imply though that there are no events outside page transitions... sounds a lot like a wizard to me :) In other words, you have something like: Action A executes to set up page A... Page A is shown... For submitted to Action A1, forward to Action B... Action B executes to set up Page B... Page B is shown... ...and so on... Nothing unusual there, except that no Action would ever return a forward that points directly to a JSP, except a setup Action... Action A1 for instance would return a forward that points to Action B's mapping. Frank --- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
On 2/15/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: On Wed, February 15, 2006 2:46 pm, [EMAIL PROTECTED] said: Is it, however, possible that you could design you application to where all the mapped actions were setup actions? I guess not. Yes you can. In this case you need to somehow distinguish the semantics of the request: do you want to render a page or do you want to submit input data. The choices are: * distinguish by request method (POST vs. GET). This is simple and it works, but all your input must be done via POST. This is how it works in .NET and it seems that the same approach is used in JSF. Hence the term postback not getback ;-) * distinguish by presence of a certain parameter in the request (event parameter). This means, that all your input must be send along with event name, therefore DispatchAction-type actions can be used very effectively here, directing request to a method that corresponds to event. This kind of action would process both render requests and input requests, for example: http://struts.sourceforge.net/strutsdialogs/dialogaction.html This concept seems a little complex for many people who got used to a pair of setup/input actions, so I am currently revising my library to employ MappingParameterDispatchAction (http://issues.apache.org/bugzilla/show_bug.cgi?id=38343) This one is worth checking out. I hope it makes into 1.3.1 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? I guess the question to ask is what are the kinds of Actions... I don't mean DispatchAction vs. Action vs. whateve else, but the *purpose* of the Action. I can only see: * Setup Action, called when any page is first displayed * Event Handler Action, called most usually in response to a form submission. There is really two sub-types to this, one where the resultant forward returns you to the same page, and one where it brings you to another page. When you go to another page, the question is, do you forward directly to a JSP (I'd bet most people do... I know I do that most often) or does it go to another Action, which is the setup Action for the next page? An action should *never* forward to a page that does not belong to that action; this practice leads to a spaghetti code both in Java and in config file. Some people may refer to that as action chaining, but I don't think it is. If you always forward to another Action, instead of directly to JSPs, what your rally doing is creating almost a prerender phase to the next page. I would say slightly different: what you really doing is transferring control to another web resource and you *do not care* which page will be shown. To select and to setup a proper page is the task of the resource you are forwarding to. You also are giving yourself the opportunity to have more information, not to mention control, over what goes on. Exactly, and to break your spaghetti-mappings into separate self-contained chunks. In that way, I suppose you *could* create an app that was nothing but setup actions... that would imply though that there are no events outside page transitions... What do you mean? As I see it, every page (or a set of pages) belong to a particular pair of setup action / input action (or to a single dialog action). Setup action (I call it render action) renders a page. When you click anywhere on this page or sumbit a form, event goes to an input action that belongs to this web resource. Event does not go outside! Only an action can transfer control to another action. Action A executes to set up page A... Page A is shown... For submitted to Action A1, forward to Action B... Action B executes to set up Page B... Page B is shown... ...and so on... If A and A1 belong to the same resource, then I agree with that. I would use redirect instead of forward simply to prevent double submit issues. What if you refresh page B? Redirection between resources does not imply that actionforms must be session-scoped ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
Michael Jouravlev wrote: An action should *never* forward to a page that does not belong to that action; this practice leads to a spaghetti code both in Java and in config file. If you mean forward directly to a JSP, I agree. If you meant something else, I'm not sure how you would ever get to another page :) I would say slightly different: what you really doing is transferring control to another web resource and you *do not care* which page will be shown. To select and to setup a proper page is the task of the resource you are forwarding to. Yep, I think you meant what I said above :) I agree. In that way, I suppose you *could* create an app that was nothing but setup actions... that would imply though that there are no events outside page transitions... What do you mean? As I see it, every page (or a set of pages) belong to a particular pair of setup action / input action (or to a single dialog action). Setup action (I call it render action) renders a page. When you click anywhere on this page or sumbit a form, event goes to an input action that belongs to this web resource. Event does not go outside! Only an action can transfer control to another action. I think we're saying the same things, just with some different terminology. As I read back what I wrote, I realized even in the situation I was trying to outline, you would *still* have setup actions and event handler actions as I think of them... I think you would use the terms render action and input action. Same idea though. Action A executes to set up page A... Page A is shown... For submitted to Action A1, forward to Action B... Action B executes to set up Page B... Page B is shown... ...and so on... If A and A1 belong to the same resource, then I agree with that. Yes, exactly. I would use redirect instead of forward simply to prevent double submit issues. What if you refresh page B? Redirection between resources does not imply that actionforms must be session-scoped ;-) No problem with that here, makes sense... always has, I know you've been preaching this for some time :) Frank - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
Is there any actual verification that these remarks are true? Could you give us some links? On 2/14/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/14/06, Mark Lowe [EMAIL PROTECTED] wrote: You could use the referer header to create an action forward based on that value. referer field is unreliable. Can fail depending on your mix or forwarding/redirecting/reloading a page. It is also often removed by proxies/firewalls. I would not recommend using referer field. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- You can lead a horse to water but you cannot make it float on its back. ~Dakota Jack~
Another struts design question
Greetings, I need to have an action return to a previous page depending upon which page originally requested the common page. Think of it as a settings page that can be accessed from multiple places. Like this: Entry 1 --- Common Page Entry 2 How can I tell the common page action to return to the correct requestor page? thanks, -- Keith Sader [EMAIL PROTECTED] http://www.saderfamily.org/roller/page/ksader - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
You could use the referer header to create an action forward based on that value. String referer = request.getHeader(Referer); URL url = new URL(referer); String path = url.getPath(); String contextPath = request.getContextPath(); path = path.replaceFirst(contextPath,); return new ActionForward(path,true); You may have to append any parameters to the path, but i'm sure you can work that out.. Mark On 2/14/06, Keith Sader [EMAIL PROTECTED] wrote: Greetings, I need to have an action return to a previous page depending upon which page originally requested the common page. Think of it as a settings page that can be accessed from multiple places. Like this: Entry 1 --- Common Page Entry 2 How can I tell the common page action to return to the correct requestor page? thanks, -- Keith Sader [EMAIL PROTECTED] http://www.saderfamily.org/roller/page/ksader - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
That could work, and it would scale to n input pages. Thanks Mark! On 2/14/06, Mark Lowe [EMAIL PROTECTED] wrote: You could use the referer header to create an action forward based on that value. String referer = request.getHeader(Referer); URL url = new URL(referer); String path = url.getPath(); String contextPath = request.getContextPath(); path = path.replaceFirst(contextPath,); return new ActionForward(path,true); You may have to append any parameters to the path, but i'm sure you can work that out.. -- Keith Sader [EMAIL PROTECTED] http://www.saderfamily.org/roller/page/ksader http://www.jroller.com/page/certifieddanger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
As long as you are arriving at the settings page via an action, can't you just call the getInputForward() -- the method that the validate stuff calls to return to the starting page if there were errors; this seems like it would easily work. If you aren't arriving at the settings page via an action, you can go ahead and route this through a ForwardAction -- this is suggested in several books. Probably for reasons such as this. Hope this helps. --- On Tue 02/14, Keith Sader [EMAIL PROTECTED] wrote: From: Keith Sader [mailto: [EMAIL PROTECTED] To: user@struts.apache.org Date: Tue, 14 Feb 2006 08:04:15 -0600 Subject: Re: Another struts design question That could work, and it would scale to n input pages.Thanks Mark!On 2/14/06, Mark Lowe [EMAIL PROTECTED] wrote: You could use the referer header to create an action forward based on that value. String referer = request.getHeader(Referer); URL url = new URL(referer); String path = url.getPath(); String contextPath = request.getContextPath(); path = path.replaceFirst(contextPath,); return new ActionForward(path,true); You may have to append any parameters to the path, but i'm sure you can work that out..--Keith [EMAIL PROTECTED]://www.saderfamily.org/roller/page/ksaderhttp://www.jroller.com/page/certifieddanger-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]
Re: Another struts design question
[EMAIL PROTECTED] wrote: As long as you are arriving at the settings page via an action, can't you just call the getInputForward() -- the method that the validate stuff calls to return to the starting page if there were errors; this seems like it would easily work. If you aren't arriving at the settings page via an action, you can go ahead and route this through a ForwardAction -- this is suggested in several books. Probably for reasons such as this. The OP wanted to know how to return to a previous page programatically. I've only done this for security access (you do not have access to that page so send them to login or denial page). In the past I've simply added logic to my security filter to save the page in session and redirect back to it after they've logged in. These days I guess you could put that in a request processor or something. Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
On 2/14/06, Mark Lowe [EMAIL PROTECTED] wrote: You could use the referer header to create an action forward based on that value. referer field is unreliable. Can fail depending on your mix or forwarding/redirecting/reloading a page. It is also often removed by proxies/firewalls. I would not recommend using referer field. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
On 2/14/06, Michael Jouravlev [EMAIL PROTECTED] wrote: On 2/14/06, Mark Lowe [EMAIL PROTECTED] wrote: You could use the referer header to create an action forward based on that value. referer field is unreliable. Can fail depending on your mix or forwarding/redirecting/reloading a page. It is also often removed by proxies/firewalls. I would not recommend using referer field. Fair enough, what do you suggest as an alternative? I've used this a few times for forwarding back to the referer and found any huge problems. I can see how if something removed the header that could cause problems, but cant see what would be achieved by a firewall or proxy messing around like this would achieve. The only other suggestion i would make if this were an issue is use separate action mappings for each point of entry.. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
Mark Lowe wrote the following on 2/14/2006 2:32 PM: The only other suggestion i would make if this were an issue is use separate action mappings for each point of entry.. Actually that seems pretty clean to me. Even if he has a lot of points of entry it can't be that many. Or another option is to simply embed some param that gets passed when the Action is called and you can call different forwards based on that. Simply define several forwards in the config... action path=/someAction name=someForm type=com.WhateverAction scope=request parameter=dispatch forward name=fromFooPage path=/WEB-INF/jsp/someOtherPageA.jsp/ forward name=fromBarPage path=/WEB-INF/jsp/someOtherPageB.jsp/ Or they may even be global forwards. 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). -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
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 ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
On 2/14/06, Rick Reumann [EMAIL PROTECTED] wrote: Mark Lowe wrote the following on 2/14/2006 2:32 PM: The only other suggestion i would make if this were an issue is use separate action mappings for each point of entry.. Actually that seems pretty clean to me. Even if he has a lot of points of entry it can't be that many. One occasion when i use the forward to referer was when i had a basket/cart presented all over the place.. Rather than have a boring old, go to basket page do some basket stuff, i wanted the user to be able to maniuplate the cart with out going anywhere, on anypage.. I guess there could be other ways, but sometimes you do have N amount of entry points.. Or another option is to simply embed some param that gets passed when the Action is called and you can call different forwards based on that. Simply define several forwards in the config... action path=/someAction name=someForm type=com.WhateverAction scope=request parameter=dispatch forward name=fromFooPage path=/WEB-INF/jsp/someOtherPageA.jsp/ forward name=fromBarPage path=/WEB-INF/jsp/someOtherPageB.jsp/ Or they may even be global forwards. 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). In the case of a few entry points I see how this could be okay.. But if you've something thats present through out a load of pages, I'd take my chances using the Referer header. Mark -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another struts design question
ok, I let page A or B pass a returnURL to page C who keeps it in the session scoped actionForm. On 2/15/06, Frank W. Zammetti [EMAIL PROTECTED] wrote: 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] For additional commands, e-mail: [EMAIL PROTECTED]
