<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]