Re: Form data vs request attributes
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] says... > The options of a control are only used to help the user choose a > value; its only purpose is to give the control a value and isn't > itself a value of the form. Think of it this way: the form doesn't lose > any data by changing your into an . > Confused? Think of it another way: The values don't get submitted, > only the value of the . Ahh, that make sense. Thanks. A followup question if I can... The ActionMapping that my XXXAction returns forwards to the same XXX.jsp that was used as the original input for XXXAction. I have noticed that, in XXXAction, if I change the value of one of the ActionForm variables, the JSP will plug the new value into the when it serves it back to the user. That's sort of neat, but it makes me wonder what will happen if an ActionMapping from another unrelated Action forwards to XXX.jsp. The other action may well have setup the customers variable in the context, but it is unlikely that it will have the same form as XXXAction. What happens in this case? Thanks again. -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Form data vs request attributes
The reason I don't do this is because if the form is in session scope, it hangs around consuming memory until the session goes away. As a caching mechanism, this bites rocks, because it is cached for each user. :-/ By putting this type of stuff in request scope instead of on the form, it becomes transient regardless of where the form resides. But if you use a DAO layer with caching (like iBATIS), one copy of this stuff can be cached (globally) so you are not hitting the database all the time. Larry >>> [EMAIL PROTECTED] 11/18/03 4:41 PM >>> > From: Mainguy, Mike [mailto:[EMAIL PROTECTED] > Although, I don't really see a major problem with storing the > options in the form itself (just to make things simple). > Anybody have a compelling reason NOT to do this? > i.e. I put my statesCollection as a property on my ActionForm > with a List datatype. Then I can just use the form property to > populate my options. Every time Struts instantiates your Form object, it also creates that list of states. If you have 'state' on more than one form, there's another list, times how ever many users have forms going at any one time. Since the list of states is unlikely to change, I think it makes more sense to put the list in application scope (as a context parameter) and have only one instance of it. However, memory is cheap, so it's probably not going to matter where you put it as long as you're happy with your decision. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM - 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: Form data vs request attributes
> From: Mainguy, Mike [mailto:[EMAIL PROTECTED] > Although, I don't really see a major problem with storing the > options in the form itself (just to make things simple). > Anybody have a compelling reason NOT to do this? > i.e. I put my statesCollection as a property on my ActionForm > with a List datatype. Then I can just use the form property to > populate my options. Every time Struts instantiates your Form object, it also creates that list of states. If you have 'state' on more than one form, there's another list, times how ever many users have forms going at any one time. Since the list of states is unlikely to change, I think it makes more sense to put the list in application scope (as a context parameter) and have only one instance of it. However, memory is cheap, so it's probably not going to matter where you put it as long as you're happy with your decision. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Form data vs request attributes
Although, I don't really see a major problem with storing the options in the form itself (just to make things simple). Anybody have a compelling reason NOT to do this? i.e. I put my statesCollection as a property on my ActionForm with a List datatype. Then I can just use the form property to populate my options. worse is better -Original Message- From: Hubert Rabago [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 18, 2003 6:10 PM To: Struts Users Mailing List Subject: Re: Form data vs request attributes ActionForm objects are representation of a form and the data in the form. It holds the values of your , , and other form controls. The options of a control are only used to help the user choose a value; its only purpose is to give the control a value and isn't itself a value of the form. Think of it this way: the form doesn't lose any data by changing your into an . Confused? Think of it another way: The values don't get submitted, only the value of the . So: 1) The ActionForm helps you get to the values submitted with the form, and so "suburb" is required there because it's part of the form. 2) The ActionForm doesn't hold values, only the value of the . 3) You need a way to tell what to show, and you can do it by specifying a collection that's in scope (doesn't have to be the request scope). Hope all that didn't confuse you further. --- Craig Edwards <[EMAIL PROTECTED]> wrote: > I've been fiddling around with Struts for a while now and am still a > little puzzled as to whether JSPs should be getting their data from my > DynaActionForm or from the session/request context. For example, if my > JSP contains: > > > > > > The way I have this working currently is by adding "customers" to the > request context and by having "suburb" declared in my DynaActionForm. I > don't appear to have to declare "customers" in the form, but if I don't > declare "suburb", I get an error... what is the difference? > > P.S. If it helps clarify things, the JSP I have displays a list of > customers and some input fields. The user can update the input fields, > press submit and they see the same page (with the new details displayed > in the list). Many thanks. > > -- > Craig Edwards > Sydney, Australia > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - This message and its contents (to include attachments) are the property of Kmart Corporation (Kmart) and may contain confidential and proprietary information. You are hereby notified that any disclosure, copying, or distribution of this message, or the taking of any action based on information contained herein is strictly prohibited. Unauthorized use of information contained herein may subject you to civil and criminal prosecution and penalties. If you are not the intended recipient, you should delete this message immediately. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Form data vs request attributes
ActionForm objects are representation of a form and the data in the form. It holds the values of your , , and other form controls. The options of a control are only used to help the user choose a value; its only purpose is to give the control a value and isn't itself a value of the form. Think of it this way: the form doesn't lose any data by changing your into an . Confused? Think of it another way: The values don't get submitted, only the value of the . So: 1) The ActionForm helps you get to the values submitted with the form, and so "suburb" is required there because it's part of the form. 2) The ActionForm doesn't hold values, only the value of the . 3) You need a way to tell what to show, and you can do it by specifying a collection that's in scope (doesn't have to be the request scope). Hope all that didn't confuse you further. --- Craig Edwards <[EMAIL PROTECTED]> wrote: > I've been fiddling around with Struts for a while now and am still a > little puzzled as to whether JSPs should be getting their data from my > DynaActionForm or from the session/request context. For example, if my > JSP contains: > > > > > > > The way I have this working currently is by adding "customers" to the > request context and by having "suburb" declared in my DynaActionForm. I > don't appear to have to declare "customers" in the form, but if I don't > declare "suburb", I get an error... what is the difference? > > P.S. If it helps clarify things, the JSP I have displays a list of > customers and some input fields. The user can update the input fields, > press submit and they see the same page (with the new details displayed > in the list). Many thanks. > > -- > Craig Edwards > Sydney, Australia > __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Form data vs request attributes
> I don't appear to have to declare "customers" in the form, but > if I don't declare "suburb", I get an error... what is the difference? 'suburb' is a form property, Struts will call get/setSuburb as it populates the Form Bean and generates the HTML. 'customers' is a collection of things to be used to populate a select list. It may or may not be a property of this particular form. It can live anywhere-- request scope, application scope, session scope. I don't consider the contents of a select list to be a "property" of the form, so I don't put it in the form bean. The way you're doing it is fine. If 'customers' never changes, consider using Application scope (a Context attribute). If it varies by user, session scope might work for you. That way you don't have to put it in request scope repeatedly. -- Wendy Smoak Applications Systems Analyst, Sr. Arizona State University, PA, IRM - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Form data vs request attributes
I've been fiddling around with Struts for a while now and am still a little puzzled as to whether JSPs should be getting their data from my DynaActionForm or from the session/request context. For example, if my JSP contains: The way I have this working currently is by adding "customers" to the request context and by having "suburb" declared in my DynaActionForm. I don't appear to have to declare "customers" in the form, but if I don't declare "suburb", I get an error... what is the difference? P.S. If it helps clarify things, the JSP I have displays a list of customers and some input fields. The user can update the input fields, press submit and they see the same page (with the new details displayed in the list). Many thanks. -- Craig Edwards Sydney, Australia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
