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