tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Larry Isaacs <Larry.Isa...@sas.com>
Subject RE: Proper jsp:setProperty behavior for Tomcat 3.2
Date Mon, 20 Nov 2000 14:52:46 GMT
I have a patch that assumes for indexed properties, empty parameter
values should be ignored as is done for simple properties.  Thus,
for the following test cases:

1) <jsp:setProperty name="bean" property="prop" param="prop"/>
2) <jsp:setProperty name="bean" property="prop"/>
3) <jsp:setProperty name="bean" property="*"/>
 
the following results would occur for the specified query string:
 
Query String      Result1     Result2     Result3
?prop=            not changed not changed not changed
?prop=&prop=      not changed not changed not changed
?prop=&prop=text  "text"      "text"      "text"

I think this is would be an improvement over the current behavior.
If we don't hear something definitive from Eduardo, I can go ahead
and commit it this afternoon if no one objects.  I will at least
fix the value="" handling.

As is often the case for me, one issue seem to always lead to another.
Here, the next issue is what should happen for simple properties when
multiple values of the parameter appear in the query string.  Currently
Tomcat 3.2 and 3.3 always use the first value found in the query
strings, i.e. for a simple string property the cases:

1) <jsp:setProperty name="bean" property="prop"/>
2) <jsp:setProperty name="bean" property="*"

give the following results:

Query String            Result1     Result2
?prop=&prop=text        not changed	not changed
?prop=text&prop=        "text"      "text"
?prop=text&prop=text2   "text"      "text"

Should passing multiple values to a simple property be an error?  I
haven't done a lot of HTML, but discussions with someone who has
seemed to indicate that the sequence of parameters in the query string
isn't reliable.  Thus, you couldn't count on how your webapp would
behave.  If this is the case, I think the spec should at least warn
users not to do this.


Cheers,
Larry

Mime
View raw message