I would rather see that controlled by a property.  

> -----Original Message-----
> From: Henning P. Schmiedehausen [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 17, 2003 2:27 AM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs commit: 
> jakarta-turbine-2/src/java/org/apache/turbine/services/intake/
> model StringField.java
> 
> 
> "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]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to