chained actions
I don't understand what is happening: I am chaining to Actions that use the same form input. when i submit the form, Action1 is called, and the form parameter is well populated. at the end of action1, I make a forward to Action2. and in Action2, the form is emptied!!??? I don't understand what is happening, and why. the solution I have found is not to specify a form bean for action2 and get it by request.getAttribute(MyForm). i t works, but I would like to understand why struts creates a new form bean, overriding the existing one. I hope someone will explain me. Caroline PS: here is a snippet of struts-config.xml, Action1.java and Action2.java action path=/action1 type=package.Action1 name=MyForm scope=request forward name=ok path=/action2.do/ /action action path=/action2 type=package.Action2 name=MyForm scope=request forward name=ok path=nextpage/ /action /// Action1 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs a value /// Action2 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs null - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: chained actions
Action chaining is considered bad practice. There are numerous threads discussing the reasons - search the archive for details. Remember of course that when you hit the second action the RequestProcessor executes again - this means that reset() is called again - and the form repopulated - which makes your symptoms emptied kind of strange - one would expect to see the form repopulated from the request (with changes you made to its contents in the first action being written over) but not emptied (unless none of those properties were in the request but were cleared in reset). Are you using a redirecting forward? hmmm. No you cant be if you can still find the form in the request. Anyhow, these are just the tip of the iceberg when it comes to the sort of fun problems you get from commiting the sin of action chaining. -Original Message- From: Caroline Lauferon [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 November 2003 16:55 To: Struts Users Mailing List Subject: chained actions I don't understand what is happening: I am chaining to Actions that use the same form input. when i submit the form, Action1 is called, and the form parameter is well populated. at the end of action1, I make a forward to Action2. and in Action2, the form is emptied!!??? I don't understand what is happening, and why. the solution I have found is not to specify a form bean for action2 and get it by request.getAttribute(MyForm). i t works, but I would like to understand why struts creates a new form bean, overriding the existing one. I hope someone will explain me. Caroline PS: here is a snippet of struts-config.xml, Action1.java and Action2.java action path=/action1 type=package.Action1 name=MyForm scope=request forward name=ok path=/action2.do/ /action action path=/action2 type=package.Action2 name=MyForm scope=request forward name=ok path=nextpage/ /action /// Action1 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs a value /// Action2 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs null - 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: chained actions
Hi Caroline, the only reason that I know of which would explain the loss of the form property values is redirecting from action1 to action2, but your action mappings don't show redirect=true. Are you redirecting by default somehow? I know it is possible for instance with an init-param on your action servlet config in web.xml. Adam PS Andrew - limited action chaining isn't that bad. Are you claiming you don't do any at all? On 11/19/2003 09:55 AM Caroline Lauferon wrote: I don't understand what is happening: I am chaining to Actions that use the same form input. when i submit the form, Action1 is called, and the form parameter is well populated. at the end of action1, I make a forward to Action2. and in Action2, the form is emptied!!??? I don't understand what is happening, and why. the solution I have found is not to specify a form bean for action2 and get it by request.getAttribute(MyForm). i t works, but I would like to understand why struts creates a new form bean, overriding the existing one. I hope someone will explain me. Caroline PS: here is a snippet of struts-config.xml, Action1.java and Action2.java action path=/action1 type=package.Action1 name=MyForm scope=request forward name=ok path=/action2.do/ /action action path=/action2 type=package.Action2 name=MyForm scope=request forward name=ok path=nextpage/ /action /// Action1 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs a value /// Action2 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs null -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: chained actions
Cant be redirecting though. If it was then one would not be able to retrieve the form object from the request attributes in the second action. My guess it that the parameters in question are being set in the first action and there isnt actually a corresponding parameter value in the request and they are then cleared by reset() prior toi hitting action 2. Is this the case Caroline? snip PS Andrew - limited action chaining isn't that bad. Are you claiming you don't do any at all? /snip Ah.. ahem, well I Im only human, and sometimes ... well you know... but its not something Im proud of ok. blush/ -Original Message- From: Adam Hardy [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 November 2003 17:11 To: Struts Users Mailing List Subject: Re: chained actions Hi Caroline, the only reason that I know of which would explain the loss of the form property values is redirecting from action1 to action2, but your action mappings don't show redirect=true. Are you redirecting by default somehow? I know it is possible for instance with an init-param on your action servlet config in web.xml. Adam PS Andrew - limited action chaining isn't that bad. Are you claiming you don't do any at all? On 11/19/2003 09:55 AM Caroline Lauferon wrote: I don't understand what is happening: I am chaining to Actions that use the same form input. when i submit the form, Action1 is called, and the form parameter is well populated. at the end of action1, I make a forward to Action2. and in Action2, the form is emptied!!??? I don't understand what is happening, and why. the solution I have found is not to specify a form bean for action2 and get it by request.getAttribute(MyForm). i t works, but I would like to understand why struts creates a new form bean, overriding the existing one. I hope someone will explain me. Caroline PS: here is a snippet of struts-config.xml, Action1.java and Action2.java action path=/action1 type=package.Action1 name=MyForm scope=request forward name=ok path=/action2.do/ /action action path=/action2 type=package.Action2 name=MyForm scope=request forward name=ok path=nextpage/ /action /// Action1 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs a value /// Action2 MyForm f = (MyForm ) a_form; s_logger.info(f.getField1() : + f.getField1()); // outputs null -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - 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: chained actions
My guess it that the parameters in question are being set in the first action and there isnt actually a corresponding parameter value in the request and they are then cleared by reset() prior toi hitting action 2. Is this the case Caroline? I'm not sure I understand what you mean do you mean the form fields by parameters? If so, that's not what i am doing. My form has several submission buttons. Action1 is just logging the field values and forwarding to the action corresponding to the button used to submit. No modification is made. i found in the archives: when the second action is being invoked, the form is being 'repopulated' with the initial form values that the form had when it was passed to the first action . and that's not what is happening :-( Caroline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: chained actions
snip I'm not sure I understand what you mean do you mean the form fields by parameters? /snip Yes. Thats what I mean. In this case you say you arent modifying any of the form properties but just forwarding straight to the next action. This is quite mysterious actually. Based on all the info you have given it should be working! Hmmm. Is it a multipart form (file upload)? Definately no exceptions/errors from struts in the log? Can you dump the request parameters in the second action to make sure the parameters are there? Also try putting a logging statement in the forms reset() method to see if its being called again for the second action. -Original Message- From: Caroline Lauferon [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 November 2003 17:33 To: Struts Users Mailing List; [EMAIL PROTECTED] Subject: Re: chained actions My guess it that the parameters in question are being set in the first action and there isnt actually a corresponding parameter value in the request and they are then cleared by reset() prior toi hitting action 2. Is this the case Caroline? I'm not sure I understand what you mean do you mean the form fields by parameters? If so, that's not what i am doing. My form has several submission buttons. Action1 is just logging the field values and forwarding to the action corresponding to the button used to submit. No modification is made. i found in the archives: when the second action is being invoked, the form is being 'repopulated' with the initial form values that the form had when it was passed to the first action . and that's not what is happening :-( Caroline - 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: chained actions
Is it a multipart form (file upload)? yes. and since you asked me, I just changed it. and now it works??? (but the reset method is called between the two action in both cases). I don't need this encoding, but I wanted to always use the same skeleton, that's why i used it. can you explain me what has been happening? Caroline, puzzled - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chained actions
Here is what happens : reset() is called before every form population form population occurs before every struts action url (*.do) is processed. When an action forwards to another one using forward path=another.do, struts actionServlet is called to handle this second URL. FormBean is then reseted and populated from request. If you doesn't use a redirect, request is the same an all parameters are still in it, so formbean is populated the same way for the two actions. If you use a redirect, when first action forwards, a HTTP Redirect response (with location=another.do) is sent to the browser. Browser follows new location and builds a new request, but this new request hasn't any parameter. When form population occurs for another.do, form-bean is reseted and population has no effect (no parameters !). Nico. - Original Message - From: Caroline Lauferon [EMAIL PROTECTED] To: [EMAIL PROTECTED]; Struts Users Mailing List [EMAIL PROTECTED] Sent: Wednesday, November 19, 2003 11:31 AM Subject: Re: chained actions Is it a multipart form (file upload)? yes. and since you asked me, I just changed it. and now it works??? (but the reset method is called between the two action in both cases). I don't need this encoding, but I wanted to always use the same skeleton, that's why i used it. can you explain me what has been happening? Caroline, puzzled - 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: chained actions
Ahhh. Multipart requests are funny beasts. They dont work the same way as normal requests. In a normal request the servlet container will parse the request and initialise the request parameters in the request object (which you can then obtain through such calls as request.getParameter(bob)). Multipart requests however are submitted a different way to normal requests. The servlet container is too stuck up to associate with such working-class request types (something to do with the format being merely an RFC and not an official standard or some such bourgeious nonsense) and so for a multipart request, getParameter() will return null!!! This is where struts comes in. Struts is much nicer than your average servlet container, and it provides special support for multipart requests to help make them act like normal requests for most purposes. (Well actually I think its in some commons project now that struts leverages off - but the origin of this code was actually in struts so I'll just lump it all in together as Struts for the purposes of this discussion). When a multipart request is submitted the request parameters arent initialised by your servlet container. Struts will create a RequestWrapper object to wrap the request and it will read from the requests input stream and initialise the parameters in this RequestWrapper object. (It will also read the files being uploaded and create the FormFile objects for the file fields if there are any). The request object that gets passed to your action is thus in fact this Multipart request wrapper object created by struts. (You can verify this by comparing the results of a request.getClass().getName() call for a multipart and non-multipart request sent to your action). When the action has finished processing the request processor will unwrap the request wrapper it created and forward based on the original request object. Now what I think is happening to you here (and Im not 100% sure) is that when the second action is hit, the input stream for the request has been read already and cannot be re-read - and thus the multipart request cant be processed a second time. Your best bet for a workaround is to do something like what you were doing before - store a reference to the actionform populated for the first request and look this up in the second. hth Andrew -Original Message- From: Caroline Lauferon [mailto:[EMAIL PROTECTED] Sent: Wednesday, 19 November 2003 18:32 To: [EMAIL PROTECTED]; Struts Users Mailing List Subject: Re: chained actions Is it a multipart form (file upload)? yes. and since you asked me, I just changed it. and now it works??? (but the reset method is called between the two action in both cases). I don't need this encoding, but I wanted to always use the same skeleton, that's why i used it. can you explain me what has been happening? Caroline, puzzled - 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: chained actions
Wahouh! thanks a lot for your great explanation! thanks to all those who have also helped me: Adam Hardy and Nicolas De Loof ;-) Caroline - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: chained actions
On 11/19/2003 12:13 PM Caroline Lauferon wrote: Wahouh! thanks a lot for your great explanation! thanks to all those who have also helped me: Adam Hardy and Nicolas De Loof ;-) and thanks Andrew from me too - I never knew that. Adam -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problem with chained actions in IE it work while Mozilla(Firebird) shows 404 (the context path gets lost)
Hello togehter, in my application I have a series of chained Actions defined like this: action path=/setupModifyData type=activegroup.hdb.struts.action.LockDatasetAction scope=request name=insertDataForm validate=false forward name=Success path=/preloadData.do / /action action path=/preloadData type=activegroup.hdb.struts.action.ModifyPreloadAction scope=request name=insertDataForm validate=false forward name=Success path=/jsp/modifyData.jsp / forward name=Failure path=/unlockDataset.do / forward name=View_Only path=/jsp/viewData.jsp / /action action path=/modifyData type=activegroup.hdb.struts.action.ModifyDataAction scope=request name=insertDataForm validate=true input=/jsp/modifyData.jsp forward name=Success path=/unlockDataset.do / forward name=Failure path=/unlockDataset.do / /action action path=/unlockDataset type=activegroup.hdb.struts.action.UnlockDatasetAction scope=request name=insertDataForm validate=true input=/jsp/modifyData.jsp forward name=Success path=/jsp/closeAndReload.jsp / /action When I call (by click on a link) the /setupModifyData.do action in IE the dataset is locked and the appcontext/jsp/modifyData.jsp showes up. When I click on the same link in Mozilla(Firebird) a 404 Error is shown because the appcontext gets lost somewhere and the resource /jsp/modifyData.jsp could not be found. Why does this happen? Martin Grüneberg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: problem with chained actions in IE it work while Mozilla(Firebird) shows 404 (the context path gets lost) (SOLVED)
Solved, it was only a Browser caching problem -Ursprüngliche Nachricht- Von: Martin Grüneberg [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. Oktober 2003 11:10 An: [EMAIL PROTECTED] Betreff: problem with chained actions in IE it work while Mozilla(Firebird) shows 404 (the context path gets lost) Hello togehter, in my application I have a series of chained Actions defined like this: action path=/setupModifyData type=activegroup.hdb.struts.action.LockDatasetAction scope=request name=insertDataForm validate=false forward name=Success path=/preloadData.do / /action action path=/preloadData type=activegroup.hdb.struts.action.ModifyPreloadAction scope=request name=insertDataForm validate=false forward name=Success path=/jsp/modifyData.jsp / forward name=Failure path=/unlockDataset.do / forward name=View_Only path=/jsp/viewData.jsp / /action action path=/modifyData type=activegroup.hdb.struts.action.ModifyDataAction scope=request name=insertDataForm validate=true input=/jsp/modifyData.jsp forward name=Success path=/unlockDataset.do / forward name=Failure path=/unlockDataset.do / /action action path=/unlockDataset type=activegroup.hdb.struts.action.UnlockDatasetAction scope=request name=insertDataForm validate=true input=/jsp/modifyData.jsp forward name=Success path=/jsp/closeAndReload.jsp / /action When I call (by click on a link) the /setupModifyData.do action in IE the dataset is locked and the appcontext/jsp/modifyData.jsp showes up. When I click on the same link in Mozilla(Firebird) a 404 Error is shown because the appcontext gets lost somewhere and the resource /jsp/modifyData.jsp could not be found. Why does this happen? Martin Grüneberg - 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]
Chained Actions (why so bad?), forwards vs. redirects, and Tiles
I'm still not seeing why 'chained' actions are so bad. On our current project, we want a user who has just signed up to go ahead and be logged-in all in the same step, and forwarded straight to the logged-in homepage. There are 2 actions, and using 1.1b3 with Tiles, the following struts-config worked just fine: action path=/signup ... forward name=login path=login.do/ /action action path=/login ... forward name=success path=tile.homepage/ /action We even figured out that you could specify the next 'link' of the chain with it's own request parameters, ala path=login.do?someparm=hello. Note that it _forwarded_ to the next action (same request object, so we could pass data as attributes), and re-triggering the dispatcher was a-ok. So then we switched to 1.1final, and noticed this doesn't work any more (Cannot get request dispatcher for path...). Now, I can understand how pulling path=login.do?someparm=hello in a forward shouldn't work (even stepping through the code, I still can't figure out how it was working before), but for a number of circumstances, I still want to be able to _forward_ to other actions. Why is that so bad? I'm not entirely seeing how it's breaking the MVC pattern. The intent of an action is to perform a discreet activity so you're not duplicating code everywhere, so to get 2 or more to execute on one request seems completely within reason. I realize there's no way to change request parameters, so yes, I'd be using request attributes to pass data between actions, so I suppose that's the whole riff over chained actions? the 'bad' practice of using request attributes? Would it be bad if I didn't need to pass anything to the next action? I'd argue using a redirect (forward redirect=true...) can be looked down on too, as it can be effected by the visitor's browser, play tricks on hit logging and clickstream tracking systems, potentially leave slow-connection users with blank screens, etc. but I digress... In _lieu_ (;^) of being able to forward to other actions, I can think of a number of other ways to work this. For a second action in the chain who wants a simple, request-scoped form, I don't mind having the first action create a form and set data, place it on the request, and use a mapping to the next action. Or, change the form to be session scoped, create the form and set data, place it in the session (you'd have to use the struts-config given name as the key, and that'd be icky), use a redirect=true mapping to get to the second action, have the second action remove it from the session. Or, have the first action create a full URL to the second action, with query string to pass parameters in, and return a redirected ActionForward (oh the semantics!). Then complicate matters of how to add, and ensure use of, https in this mix. whew. Thanks, david +1-303-218-4716 work³ +1-303-521-8967 mobile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Chained Actions (why so bad?), forwards vs. redirects, and Tiles
snip Now, I can understand how pulling path=login.do?someparm=hello in a forward shouldn't work (even stepping through the code, I still can't figure out how it was working before /snip Theres no problem slipping query params into a forward url like that. Its a standard technique. All my apps depend on it. Look elsewhere for your bug for it lyeth not in the forwarded params. btw: redirecting to another action is not action chaining. Its only chaining if you do it on the server side (non-redirecting), and its only evil as you can get (a lot of) unanticipated side-effects from a second pass through the request processor (such as form repopulation) -Original Message- From: Thompson, David [mailto:[EMAIL PROTECTED] Sent: Thursday, 18 September 2003 03:26 To: '[EMAIL PROTECTED]' Subject: Chained Actions (why so bad?), forwards vs. redirects, and Tiles I'm still not seeing why 'chained' actions are so bad. On our current project, we want a user who has just signed up to go ahead and be logged-in all in the same step, and forwarded straight to the logged-in homepage. There are 2 actions, and using 1.1b3 with Tiles, the following struts-config worked just fine: action path=/signup ... forward name=login path=login.do/ /action action path=/login ... forward name=success path=tile.homepage/ /action We even figured out that you could specify the next 'link' of the chain with it's own request parameters, ala path=login.do?someparm=hello. Note that it _forwarded_ to the next action (same request object, so we could pass data as attributes), and re-triggering the dispatcher was a-ok. So then we switched to 1.1final, and noticed this doesn't work any more (Cannot get request dispatcher for path...). Now, I can understand how pulling path=login.do?someparm=hello in a forward shouldn't work (even stepping through the code, I still can't figure out how it was working before), but for a number of circumstances, I still want to be able to _forward_ to other actions. Why is that so bad? I'm not entirely seeing how it's breaking the MVC pattern. The intent of an action is to perform a discreet activity so you're not duplicating code everywhere, so to get 2 or more to execute on one request seems completely within reason. I realize there's no way to change request parameters, so yes, I'd be using request attributes to pass data between actions, so I suppose that's the whole riff over chained actions? the 'bad' practice of using request attributes? Would it be bad if I didn't need to pass anything to the next action? I'd argue using a redirect (forward redirect=true...) can be looked down on too, as it can be effected by the visitor's browser, play tricks on hit logging and clickstream tracking systems, potentially leave slow-connection users with blank screens, etc. but I digress... In _lieu_ (;^) of being able to forward to other actions, I can think of a number of other ways to work this. For a second action in the chain who wants a simple, request-scoped form, I don't mind having the first action create a form and set data, place it on the request, and use a mapping to the next action. Or, change the form to be session scoped, create the form and set data, place it in the session (you'd have to use the struts-config given name as the key, and that'd be icky), use a redirect=true mapping to get to the second action, have the second action remove it from the session. Or, have the first action create a full URL to the second action, with query string to pass parameters in, and return a redirected ActionForward (oh the semantics!). Then complicate matters of how to add, and ensure use of, https in this mix. whew. Thanks, david +1-303-218-4716 work³ +1-303-521-8967 mobile - 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]
