Why does struts repost the HttpRequest parameters into an existing/recycled form instance of the same type at the same scope when an action mapping "action forwards" to another action mapping? Action mapping "mapping1" names "form1" at request scope and it accepts the posted data. The action mapping "action forwards" to another action mapping "mapping2" which also names "form1" at request scope. During the transition from one action to the other, struts locates the existing form at request scope, "recycles" the instance, and then reposts the data into it. I'm sure there is a good reason why this behavior is desired. Could someone post a brief scenario or situation where this would be the appropriate behavior? I can understand this behavior if the form is of a different type or or at a different scope. Background info. Please ignore unless you're bored My application is particularly complex navigationally and highly dynamic. Because of this there is a desire to model the navigational decision makers as actions and then use struts-config action forwards to, in effect, "draw lines between" the actions. However, if one of these decision makers needs to establish parameters for another existing action, it cannot effectively pass those parameters to another action without passing them as request *attributes* (since the *parameters* are not mutable in the request). The parameter is usually a single key value that could be thought of as a primary key. Regards, Matthew Marquand Object Ovation, Inc.
Joined: Dec 19, 2002
I just read "Struts In Action", Chapter 8.4. I had some pretty clear text related to this topic. However, I'm a little unclear on a couple issues: 1) Generally this is a sign that the business logic is too strongly coupled with the Action or 2) The Action hierarchy is too shallow In our situation, it's not desirable for the "exit" action to determine "where to go" and then to have it obtain the necessary object, get it on a form (of a different type I'll add) and then forward to the Tiles jsp. The domain of object types that might need to be loaded as well as what page to end up on is almost mind numbing in this application. That's why we just have the "exit" action do what it's designed to do and then have it forward to another decision point at which point it can prepare the data for the Tiles rendering. So given that long winded diatribe it doesn't feel right to deepen the hierarchy just so two actions can share code since it doesn't feel right that the exit action should be concerned with what comes after it in the flow. So I'm left with item 1 and I don't really know how to apply that statement to see if it holds true in our situation. Regards, Matthew Marquand Object Ovation, Inc.