----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>; "Deadman, Hal"
<[EMAIL PROTECTED]>
Sent: Saturday, April 06, 2002 5:08 PM
Subject: Re: use of pluggable converters in ConvertUtils changes Struts
behavior for primitive wrapper properties
> Grumble grumble ...
>
> I would sure argue that the Struts 1.0 behavior is a bug. The biggest
> problem is the inconsistency between the native types and the wrapper
> classes. In Struts 1.0:
>
> ConvertUtils.convert("1a3", Integer.TYPE) --> 0 (the default value)
> ConvertUtils.convert("1a3", Integer.class) --> null
>
> I think that the current behavior of commons-beanutils is more
> sensible, even though it is different:
>
> ConvertUtils.convert("1a3", Integer.TYPE) --> 0 (the default value)
> ConvertUtils.convert("1a3", Integer.class) --> 0 (the default value)
>
> What do you guys think? (Note that this only affects people who use the
> wrapper classes like java.lang.Integer for your property values -- if you
> have been using the Java primitive types, you will have been receiving a
> zero all along.)
I actually think the Struts 1.0 behaviour is preferable. The way I view it
is that using Integer enables the distinction between a specified zero value
and an invalid or unspecified value. If that distinction is not necessary,
then an int can be used. In other words, if Integer can provide more
functionality than int, then why not expose that additional functionality,
rather than "dumbing down" the use of Integer?
Then again, if I can configure conversion failure to return null (as
described below), then I probably don't care much...
--
Martin Cooper
>
> The second part of Hal's bug report on this (#7784) points out that there
> is no way to define null as the default value to be returned on conversion
> errors. I'm going to address that by making it possible to declare this
> is what you want.
>
> Craig
>
>
> On Tue, 26 Mar 2002, Deadman, Hal wrote:
>
> > Date: Tue, 26 Mar 2002 21:18:03 -0500
> > From: "Deadman, Hal" <[EMAIL PROTECTED]>
> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>,
> > "Deadman, Hal" <[EMAIL PROTECTED]>
> > To: 'Struts Dev List' <[EMAIL PROTECTED]>
> > Subject: use of pluggable converters in ConvertUtils changes Struts
> > behavior for primitive wrapper properties
> >
> > I think the addition of pluggable converters in ConvertUtils on 3/18 has
> > changed the way Struts handles empty form fields that map to primitive
> > Wrapper bean properties. The default IntegerConverter uses a default
value
> > of Integer(0) instead of null.
> >
> > This is a fairly significant problem because it's not backwards
compatible
> > with Struts 1.0. I often store id#s in hidden form fields that map to a
Long
> > or Integer property on the serverside bean. If the hidden field is empty
""
> > in the html then Struts used to populate the setBlah(Integer) method
with a
> > null, now it passes a zero. That causes me to try an update of entity 0
> > instead of adding a new entity, for example.
> >
> > I modified the struts-exercise-taglib to add a test to demonstrate this
> > problem. Below are the patches to the two files that would need to be
> > changed.
> >
> > -- add to struts-exercise-taglib html-setters.jsp
> >
> > <tr>
> > <th align="right">integerProperty</th>
> > <td align="left">
> > <html:text property="integerProperty" size="32"/>
> > </td>
> > <th align="right">nested.integerProperty</th>
> > <td align="left">
> > <html:text property="nested.integerProperty" size="32"/>
> > </td>
> > </tr>
> >
> >
> > -- add to TestBean in .../webapp/exercise
> >
> > /**
> > * An integer property.
> > */
> > private Integer integerProperty = new Integer(123);
> >
> > public Integer getIntegerProperty() {
> > return (this.integerProperty);
> > }
> >
> > public void setIntegerProperty(Integer integerProperty) {
> > this.integerProperty = integerProperty;
> > }
> >
> > --
> > To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
