Hi,
I agree with you that the property attribute for form element is "overloaded" to
have two meanings. It determines both:
1)which getter method will be invoked on the form bean to obtain its initial value;
2)which setter method will be invoked on the form bean (or the name of the request
parameter will be used for this element) to store its current value.
Well, I aslo feel that handling situations where multiple checkboxes share the same
name is quite confusing and complex in Struts, as the form-bean property refers to
a SINGLE data row, but the request parameter can have an ARRAY of values.
It seems to me that one straightforward workaround for this is to avoid multiple
checkboxes sharing the same name, by using different names for all those fields.
Such as:
group_check1="on"&group_check2="on"
where value can only be "on" and parameter name now indicates its real value.
Hope this helps,
Shengmeng Liu
****************************************************
----- Original Message -----
From: "David M. Karr" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, January 01, 2002 8:46 AM
Subject: Array of checkboxes in JSP -> props in bean
> I've noticed some problems, and have some questions, with situations where I
> use "logic:iterate" to display a list of checkboxes and then (hopefully)
> automatically populate those values in the downstream form object. I'm sure
> I'm misunderstanding some things, so please correct me if you see a
> misstatement. I've asked about some of this in the past, but I don't believe I
> ever got an answer (except for some direct responses to me asking if I ever got
> a response).
>
> The first issue is the use of the "property" attribute in "html:checkbox". If
> I understand this correctly, the value of this attribute is "overloaded" to
> have two meanings. The first interpretation is as the attribute of the bean
> specified as the "name" attribute in this element. This value is apparently
> used as the "current value" of the checkbox, although I'm not really sure what
> that means. I don't see the real purpose for htis. When I render a
> html:checkbox, unless I specifically use "bean:write" to print the value,
> nothing is displayed except the checkbox, so it's apparently not used for the
> rendered text.
>
> Then, the second interpretation of the "property" attribute is the name of the
> outgoing request parameter. This causes some confusion wrt checkboxes, because
> the first interpretation refers to a SINGLE data row, but the second
> interpretation essentially refers to an ARRAY of items. This is because the
> name of the request parameter associated with a set of checkboxes will get
> multiple values associated with that request parameter.
>
> For instance, if the field of the bean representing is "objectName", then the
> "property" attribute will be set to "objectName". Then, in the downstream
> form/action objects, we expect to find an ARRAY of values associated with
> "objectName". It might be less confusing if the "property" attribute wasn't
> overloaded in this situation, so that one attribute specified the property of
> the bean, and another attribute specified the name of the request parameter to
> set.
>
> The second issue is with automatic population of properties in downstream forms
> from request parameters. In general, this works pretty well. However, I don't
> see what's supposed to happen when the request parameter is multi-valued, like
> from a set of checkboxes. If I were to guess, I would think I would have to
> add methods to my downstream form (wrt the "objectName" example) of
> "getObjectName()" and "setObjectName()", although they would return and take an
> ARRAY of strings (goes back to the first issue). However, nothing happened
> when I tried this.
>
> The third issue is the "value" attribute of both html:checkbox and html:radio.
> This will very often use a scriptlet expression, as the value will likely be an
> attribute of the bean associated with each checkbox. Is there some reason that
> a "valueProperty" attribute wouldn't be useful? This would specify the
> property of the bean that will be used for the value. It's my impression that
> it's always a good idea to avoid scriplets, if possible.
>
> Again, I'd appreciate any corrections if I've misunderstood how this is
> supposed to work.
>
> --
> ===================================================================
> David M. Karr ; Best Consulting
> [EMAIL PROTECTED] ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
