You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Tom Klaasen (TeleRelay)" <to...@telerelay.com> on 2001/10/31 17:08:31 UTC

nested iterates and the indexed attribute

Hi all,

I think I discovered a bug in struts (nightly build 20011018):

when I use nested iterates, the indexed attribute is always referring to
the innermost iterate index, not the one which name is specified.

so when I do

<logic:iterate id="beanprop" name="bean" property="props">
	<logic:iterate id="beanpropinner" name="beanprop"
property="inner">
		<html:radio name="beanprop" property="someIndex"
value="someValue" indexed="true"/>
	</logic:iterate>
</logic:iterate>

I get something like

<input type="radio" name="beanprop[0].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[2].someIndex" value="someValue">
<input type="radio" name="beanprop[0].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[2].someIndex" value="someValue">
<input type="radio" name="beanprop[3].someIndex" value="someValue">
<input type="radio" name="beanprop[4].someIndex" value="someValue">

instead of the expected

<input type="radio" name="beanprop[0].someIndex" value="someValue">
<input type="radio" name="beanprop[0].someIndex" value="someValue">
<input type="radio" name="beanprop[0].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">
<input type="radio" name="beanprop[1].someIndex" value="someValue">

(watch the indexes)

(Of course, "someValue" would be replaced by something that is computed
and makes more sense. This computation is omitted here for simplicity)

Now, should I in fact consider this a bug and try to solve this, or do
you think this is expected behaviour?


thanks,
tomK

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