Re: JSTL SQL updates: escaping quotes, default values, form validation, and efficiency

[Paul DuBois <pa...@snake.net>]

At 15:50 -0400 6/21/02, Shawn Bayern wrote:
>On Fri, 21 Jun 2002, John Hicks wrote:
>
>>  On Friday 21 June 2002 03:09 pm, you wrote:
>>  >  > I finally traced this problem to undefined request
>>  >  > parameter fields, specifically radio buttons and check
>>  >  > boxes (i.e. whenever a check box was left unchecked or
>>  >  > when the user didn't select any of a set of radio
>>  >  > buttons).
>>  >
>>  > Actually, this looks like a bug in our implementation of
>>  > <sql:param>; a null 'value' should cause the
>>  > corresponding column to be set to SQL NULL.
>>
>>  In my case, the response parameter is not defined at all. 
>>  (Apparently this is an attribute of checkboxes in HTML forms.) Should
>>  an undefined attribute produce the same results as a defined attribute
>>  with a null value?
>
>Yeah - there's no difference, formally in the Servlet API, between an
>undefined parameter and a parameter with no value.  That is, if
>request.getParameter("foo") returns null, that means that the parameter
>doesn't exist.  Whether it doesn't exist because a browser didn't set it
>or because it was never in a form isn't a detail that's accessible to a
>servlet or JSP page.
>
>Note that there *is* a difference between "" and null, which was the main
>reason we introduced the 'empty' keyword.  (That is, we wanted to provide
>page authors with a way to combine the two cases, since most of the time,
>you don't care whether a parameter is "" or null.)

Except that, for database programming, sometimes you *do* care very
much.

>
>--
>Shawn Bayern
>"JSTL in Action"   http://www.jstlbook.com
>(coming in July 2002 from Manning Publications)



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