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>