> I would argue that in such a case, the developer should not
> use an "indexed" property, but rather a simple property that
> takes a String array as argument.
> (i.e. the only difference with an "indexed property" is that
> the index setter method would not be defined).
I had not noticed the distinction of a simple property that
takes an array, and one that with an indexed setter
becomes a true "indexed" property. I thought that if the
setter set<prop>() took an array as an argument, it was
considered an indexed property.
> [I'd personally propose to the expert group to
> throw an exception if a request parameter is specified for
> an indexed property]
Consider the following where ColorBean has a "colors" property
which takes String array:
=== some HTML ===
...
<form action="a.jsp" method="get" >
<input type="checkbox" name="colors" value="red"/>Red
<input type="checkbox" name="colors" value="green"/>Green
<input type="checkbox" name="colors" value="blue"/>Blue
<input type="submit"/>
</form>
...
=== a.jsp ===
...
<jsp:useBean id="mycolors" class="ColorBean"/>
<jsp:setProperty name="mycolors" property="colors"/>
...
I wouldn't expect this to throw an exception if ColorBean
had an index setter and not throw one if it didn't.
It's not clear to me from the spec, how important the index of
an indexed property is intended to be. It only says that
the setter for an indexed property needs to take an array.
> With respect to the "multi-valued request parameter" case,
> I'd personally vote for throwing an exception.
> As a developer I'd rather know right up front
> that something is fishy rather that find out about it much
> later (after losing a bunch of hair).
> [especially if the order in which parameters are reported is
> unreliable]
+1
> But this is something that should be decided by the expert group,
> and for the time being we should leave the behavior as it
> currently stands in tomcat.
Agreed.
> With all this being said, whether or not the empty values are
> passed in the array for the setter method then does not become
> as important an issue as before.
> Only passing the non-empty values is however nicer.
I'll try to commit a patch that fixes just the following:
1) Fix value="" without allowing param="..." to set.
2) For a String array property, make "?prop=&prop=text" set the
property for property="*". Currently property="*" handling
assumes only simple properties and skips the set because
the first argument is empty.
Since proper behavior with respect to empty array element is
still unclear, I'll wait on the removal of empty array elements.
This should be addressed in a separate patch anyway.
Cheers,
Larry
