"Quinton McCombs" <[EMAIL PROTECTED]> writes:

>I would rather see that controlled by a property.  

Even better, I added code to the intake model that you can set it on a
"by field" base in the intake.xml file. This works well for me and shouldn't
change the default behaviour of getting null.

        Regards
                Henning


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


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

Reply via email to