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

Reply via email to