Indexed html:radio is broken

[Frank Lawlor <fr...@athensgroup.com>]

Maybe I'm misunderstanding how to use html:radio with
"indexed", but it seems broken to me.

If I specify:

 <logic:iterate name="ListForm" property="itemList" id="item" ... >
    ...
    <html:radio indexed="true" name="item" property="contact" ... />

then it generates code like:

    <input type="radio" name="item[0].contact" ... >
    <input type="radio" name="item[1].contact" ... >
                  ...

which puts every button in its own button group (the name
MUST stay the same)!

Further, the mapping of a button group to a collection opens
a lot of questions.  In trying to figure out how html:radio might
behave (the documentation is COMPLETELY lacking in 
semantic description!) I could think of several possible behaviors,
not all of which are exclusive.  This is even more true when
"value" is brought into the picture.

Is there some description somewhere of how this is supposed
to operate (the documentation on the website does NOT explain
any of this)?  What about examples (I found nothing useful in
the examples or the forum posts)?

Is this a bug?

Frank Lawlor
Athens Group, Inc.
(512) 345-0600 x151
Athens Group, an employee-owned consulting firm integrating technology
strategy and software solutions.




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

Re: Indexed html:radio is broken

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

>>>>> "Frank" == Frank Lawlor <fr...@athensgroup.com> writes:

    Frank> Maybe I'm misunderstanding how to use html:radio with
    Frank> "indexed", but it seems broken to me.

    Frank> If I specify:

    Frank>  <logic:iterate name="ListForm" property="itemList" id="item" ... >
    Frank>     ...
    Frank>     <html:radio indexed="true" name="item" property="contact" ... />

    Frank> then it generates code like:

    Frank>     <input type="radio" name="item[0].contact" ... >
    Frank>     <input type="radio" name="item[1].contact" ... >
    Frank>                   ...

    Frank> which puts every button in its own button group (the name
    Frank> MUST stay the same)!

    Frank> Further, the mapping of a button group to a collection opens
    Frank> a lot of questions.  In trying to figure out how html:radio might
    Frank> behave (the documentation is COMPLETELY lacking in 
    Frank> semantic description!) I could think of several possible behaviors,
    Frank> not all of which are exclusive.  This is even more true when
    Frank> "value" is brought into the picture.

    Frank> Is there some description somewhere of how this is supposed
    Frank> to operate (the documentation on the website does NOT explain
    Frank> any of this)?  What about examples (I found nothing useful in
    Frank> the examples or the forum posts)?

    Frank> Is this a bug?

I could be mistaken, but this seems related to the issue I noticed recently,
which is that the "property" attribute (and apparently, the "name"/"property"
pair, in the "indexed" case) is improperly "overloaded" to serve two purposes,
one being the name of the bean property to reference to get the initial value,
and the second being the resulting name of the HTML component.

In my limited JSP/Struts experience, it would seem to me that the addition of
the following two optional attributes might resolve this:

  "nameValue"       - The name to give the resulting HTML component
  "checkedProperty" - The bean property to get the initial value from

Essentially, using either one of these, in addition to the (still required)
"property" attribute, would divide the two purposes previously mentioned into
two separate attributes.  Technically, you could use both attributes, but that
would leave the "property" attribute with nothing to do :) .

In your case, I believe you would have wanted to set the "nameValue" property
so you could use the same name for all of the buttons in your group.

I will eventually write a RFE for this, but I'm thinking about some
ramifications of this, partially with respect to later changes related to the
JSPTL.

-- 
===================================================================
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>