> The reason I ask is that since it is my understanding that either a > new Action Form is created when the user submits the form or if one > already exists it is "reset", how can the Action Form have all of > the original data, including the one or 2 fields the user just > submitted?
The ActionForm won't have all the "original" data, just what was submitted on the form, including any hidden fields. Unless, as you say, it's in session scope. (Also note that reset does nothing by default. So it only clears what *you* tell it to clear.) If you need to redisplay the form, say because validation fails, then put an Action in front of the page that will populate the controls (and nothing else). Where ever you have a reference to that page, even in the configuration, put a reference to the Action instead. On the DEV list, we've started to call these "PageControllers" or "PageLoaders". The idea is that a "business" Action may be able to choose between several display pages. But, that Action doesn't need to know what controls are on a given page. All a business action should know is the logical name. A PageLoader Action serves as the page's proxy. It knows how to populate a certain page's controls, but it doesn't know anything about setting the control's default value. That's left to the ActionForm, which may have been pre-populated from the request or by a "business" Action. Generally, the PageLoader should also forward only to "success" and not make navigational decisions. (One possible exception being choosing between localized versions of the same page -- but that's another discussion.) Note that we don't consider this "action chaining" since the PageLoader Action is the page's proxy. It doesn't branch off to some other action to continue the business operation. Most of still recommend using a single "business" action that fulfills the request and selects a resource to complete the response. In this case, the resource completing the response is the PageLoader Action working directly with the server page. (Consider them a couple.) It's important to note that you don't *need* to put lists that populate controls on the ActionForm. The lists can also exist on a separate object (or objects) separate from the ActionForm. In fact, in a post 1.1 world, I'd recommend using a separate "chrome bean" to populate select boxes and such. You can then use DynaActionForms to represent only The ActionForm can then represent only the input fields on the form. Under Struts 1.0, I tended to use coarse-grained ActionForms that represented a series of related ActionForms (or even all the ActionForms in the application). And, I used to embed the lists for the controls too. But this was mainly to make conventional ActionForms easier to maintain. Post 1.1, I tend to use finely-grained, single-use DynaActionForms that represent the output of a given page, and then put the lists and such on a separate bean. HTH, Ted. ---- Developing Web Applications Using Open Source Tools Saturday, 3 Apr 2004, New York City http://basebeans.com/do/website On Sun, 14 Mar 2004 15:31:32 -0500, Ed Tornick wrote: > Let's assume you have a Action Form with much data, including lists > (you are using nested tags for example). When you create the Action > Form you load it up with the data from your data source wherever it > is. Let's also assume that you have set the action path in the > configuration file so that the scope of this form is request. > > If the jsp on the server that is going to create your form on the > client has only a few of the fields from the Action Form then how > much data is actually sent to the client in the httpRequest? >> > The reason I ask is that since it is my understanding that either a > new Action Form is created when the user submits the form or if one > already exists it is "reset", how can the Action Form have all of > the original data, including the one or 2 fields the user just > submitted? > > If the scope was session then it would make sense to me that the > data would still be on the server and the users input would just > modify a few fields.. but when it is request scope...This is what I > don't understand. > > > As you can see, probably a very fundamental question but it is key > to me understanding what is going on. > > > Thanks in advance for your input.. > Ed --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
