Fundamental Struts Concept

[Ed Tornick <et...@comcast.net>]

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

RE: Fundamental Struts Concept

[Robert Nocera <rn...@neosllc.com>]

Ed,

I'm not sure I understand your question exactly, but I'll answer the best I
can.

The only information that is sent to the client is the HTML that you see in
the browser.  The JSP gets converted to a servlet and the servlet just
writes to the HTTPResponse, not the HTTPRequest.  The "request" you are
referring to is gone once the server sends a response.  The JSP that builds
the form can make use of as much data as is in the request, as it is all
stored on the server side as you said.

The new ActionForm the that is created after the user submits the form, from
the HTTPRequest that the client's brower created, is indeed new and does not
have access to any previously submitted client values unless they are 1.
Persisted in some persistent storage 2. persisted in the user's HTTPSession,
or 3. we included in the JSP as hidden fields (and presumably also the new
action form).

Does that help answer your question?

-Rob


-----Original Message-----
From: Ed Tornick [mailto:etornick@comcast.net] 
Sent: Sunday, March 14, 2004 3:32 PM
To: struts-user@jakarta.apache.org
Subject: Fundamental Struts Concept

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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Fundamental Struts Concept

[Ted Husted <hu...@apache.org>]

> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org