"Quinton McCombs" <[EMAIL PROTECTED]> writes:
In my case, I have a bean with a "name", a "description" and a
"comment" field. Name _must_ contain something, the user must fill out
this value. Comment and description are optional. So for Intake, Name
is required, Comment and Description are optional.
As the database entries are used for display purposes, I don't want to
put "NULL" values into the database. And the user did enter
something: An empty String ("" that is, not NULL).
The problem is, that the current Intake code doesn't distinguish
between these things (Field is missing (-> NULL) and Field exists, but
doesn't contain anything (-> "")).
We could revert to the old behaviour but then I would like to add a
property to control this.
Regards
Henning
>> -----Original Message-----
>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, July 15, 2003 5:14 AM
>> To: [EMAIL PROTECTED]
>> Subject: cvs commit:
>> jakarta-turbine-2/src/java/org/apache/turbine/services/intake/
>> model StringField.java
>>
>>
>> henning 2003/07/15 03:13:57
>>
>> Modified: src/java/org/apache/turbine/services/intake/model
>> StringField.java
>> Log:
>> While this is a simple checkin, it fixes a not quite so simple bug
>> (IMHO). The problem was dragged in in the 1.3 revision changes made
>> by quinton. There as a test added that said "if the
>> supplied string is
>> empty or null value", then set this field to "null".
>>
>> This is fine, as long as all of the fields in your form are
>> "required". Now I have an application that has a few
>> "required" fields
>> and quite some "non-required" fields. So they're submitted
>> empty by the
>> user. As they're empty and valid (they're not required),
>> its value (the
>> empty string) ends up in doSetValue. Here the test tells
>> the StringField
>> to put "null" into its internal value.
>>
>> This null value is propagated via setProperties(Object obj) to an
>> underlying bean. I use a torque generated object here, which in turn
>> inserts it value into a database table. Where the column is
>> defined as
>> required="true", which should 'just work'. Because the user sent the
>> empty String ("") to the application.
>>
>> However, the null value in the bean is translated to SQL NULL. Which
>> in turn gets refused by the database (required == NOT NULL). So the
>> user gets an errors which is not clear at all.
>Why would you not require a value for the field and yet have the underlying
>database column NOT NULL? Would you not also consider storing an empty
>string in a required database column a violation of the constraint?
>>
>> IMHO this behaviour of Intake is a bug. An empty string should be an
>> empty string in Intake, too. We can discuss about the behaviour when
>> "null" is passed to doSetValue() in the StringField, which would
>> restore the behaviour before the 1.3 revision (and similar with
>> Fulcrum, which uses quite different code).
>>
>> Discussion wanted.
>>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen INTERMETA GmbH
[EMAIL PROTECTED] +49 9131 50 654 0 http://www.intermeta.de/
Java, perl, Solaris, Linux, xSP Consulting, Web Services
freelance consultant -- Jakarta Turbine Development -- hero for hire
--- Quote of the week: "It is pointless to tell people anything when
you know that they won't process the message." --- Jonathan Revusky
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
