Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <3A196A83.533FA6DF@sun.com>
Date: Mon, 20 Nov 2000 10:16:35 -0800
From: Pierre Delisle <pierre.delisle@sun.com>
MIME-Version: 1.0
To: tomcat-dev@jakarta.apache.org
CC: Eduardo.Pelegrillopart@eng.sun.com, larry.isaacs@sun.com
Subject: Re: Proper jsp:setProperty behavior for Tomcat 3.2
References: <764CA2FF49EC054BA086FC8253A52DD743323D@merc09.us.sas.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Larry, 

As you pointed out, whether or not the sequence of parameters in 
the query string is reliable seems the key issue here.

Let's consider the following two use cases:

A) truly indexed fields

HTML form with 5 text fields labeled "Period 1" to "Period 5".
The data entered by the user in each field corresponds to the
activity he wants to register to for that specific period 
(e.g. "hockey 101" for period 3).
If these text fields all share the same parameter name (e.g. period), 
can the developer expect the values to be received in the same order 
they were defined in the form?

If the answer is no, it is obvious that the developer must use
discriminated parameter names for each field 
(e.g. period1, period2,...) to make sure the activities are
registered for the proper periods.

There is therefore no hope for something like
    <jsp:setProperty name="bean" property="period"/> 
to ever make sense with an indexed property.

B) list fields

HTML form with 5 text fields, all labeled "Activity" (no numbering).
The user simply enters the list of activities he wants to 
participate to (up to 5 activities).

Order is not important. All the developer cares is to receive
the "non-empty" values specified by the end-user.

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).

Using an indexed property does not really make sense in this
case. Won't someone use an indexed property only if the index is
relevent?

-----
So, 

If indeed the order of request parameters is not reliable,
then developers are certainly not using "indexed properties"
to handle multi-valued properties, and whatever we do in tomcat
probably has no impact (since no one uses indexed properties to handle 
indexed parameter values).

[I'd personally propose to the expert group to 
throw an exception if a request parameter is specified for 
an indexed property]

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]
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.

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.

    -- Pierre


Larry Isaacs wrote:
> 
> 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