Proposal: Add "nameValue" and "checkedProperty" to "radio" (and "checkbox"?)

["David M. Karr" <dm...@earthlink.net>]

I've often been frustrated by some details of the "radio" and "checkbox" tags.
I have some issues with the rules for producing the "name" of the resulting
element, and for deciding whether the component should be checked.  I'd like to
get some opinions on my proposed change.

The crux of the problem is that the "property" attribute is "overloaded" for
two purposes:

 1. The name of the bean property to get the current value from.
 2. The name attribute of the HTML component.

Unfortunately, it's often desirable (IMHO) for those two values to be
different.

For instance, it seems conceivable that the bean used to populate the component
would have two fields, one being a String, representing the "option name", and
the other being a boolean, indicating whether the option is on or not.  It
would be reasonable to name the boolean field "enabled".

However, using a boolean property of "enabled" means that the resulting radio
button will have a "name" attribute of "enabled", as opposed to something akin
to the "option name".

I've modified my local copy of the Struts (1.0.1rc1) so that the "radio" tag
has two additional attributes:

  "nameValue"

If present, this will be the value of the "name" attribute in the resulting
component.  If not set, the value of the "property" attribute will be used.

  "checkedProperty"

If present, the value of this property on the named bean will be compared with
"true" to determine whether this component is "checked".  If not set, it will
compare the "value" attribute against the value of the "property" property.

I've tested this change in my environment and application, and it appears to
work.  The change is backward-compatible, because if neither of these two
attributes are set, the behavior is the same as before.

When I use these attributes, however, I'm able to use a reasonable property
name for the "checked" property, and a reasonable name for the "name" of the
HTML component.

If I follow through with a patch for this, I'd obviously have to make similar
changes in the "checkbox" and "multibox" component (although I'm not familiar
with the latter component yet).  I would assume I would also need to provide
documentation and unit test patches.  I would also make the patches against the
latest in CVS, instead of the 1.0.1rc1 source release.

What do you think?

-- 
===================================================================
David M. Karr          ; Best Consulting
dmkarr@earthlink.net   ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Proposal: Add "nameValue" and "checkedProperty" to "radio" (and "checkbox"?)

["David M. Karr" <dm...@earthlink.net>]

>>>>> "David" == David M Karr <dm...@earthlink.net> writes:

    David> I've often been frustrated by some details of the "radio" and "checkbox" tags.
    David> I have some issues with the rules for producing the "name" of the resulting
    David> element, and for deciding whether the component should be checked.  I'd like to
    David> get some opinions on my proposed change.

    David> The crux of the problem is that the "property" attribute is "overloaded" for
    David> two purposes:

    David>  1. The name of the bean property to get the current value from.
    David>  2. The name attribute of the HTML component.

    David> Unfortunately, it's often desirable (IMHO) for those two values to be
    David> different.

    David> For instance, it seems conceivable that the bean used to populate the component
    David> would have two fields, one being a String, representing the "option name", and
    David> the other being a boolean, indicating whether the option is on or not.  It
    David> would be reasonable to name the boolean field "enabled".

    David> However, using a boolean property of "enabled" means that the resulting radio
    David> button will have a "name" attribute of "enabled", as opposed to something akin
    David> to the "option name".

    David> I've modified my local copy of the Struts (1.0.1rc1) so that the "radio" tag
    David> has two additional attributes:

    David>   "nameValue"

    David> If present, this will be the value of the "name" attribute in the resulting
    David> component.  If not set, the value of the "property" attribute will be used.

    David>   "checkedProperty"

Note that in my changes, I didn't change the "property" attribute, so it is
still present and required.  If both "nameValue" and "checkedProperty" are
used, then "property" is ignored (even though it's required).  However, it's
never necessary to use BOTH "nameValue" and "checkedProperty".  Since I've
divided the two purposes of "property" into two attributes, if you use one of
the new attributes, you can still have "property" be used for the other of the
two purposes.

-- 
===================================================================
David M. Karr          ; Best Consulting
dmkarr@earthlink.net   ; Java/Unix/XML/C++/X ; BrainBench CJ12P (#12004)


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>