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:
html:select property=selectedCustomer size=5
html:options
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
ActionForm objects are representation of a form and the data in the form.
It holds the values of your INPUT, SELECT, TEXTAREA and other form
controls.
The options of a SELECT control are only used to help the user choose a
value; its only purpose is to give the SELECT control a value and isn't
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
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
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
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] says...
The options of a SELECT control are only used to help the user choose a
value; its only purpose is to give the SELECT 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
7 matches
Mail list logo