Personally I like using the wrapper classes because of their ability to
represent null and I think the automatic conversion of invalid numbers to a
zero is somewhat dangerous although unavoidable since exceptions aren't an
option. Unless I am the only person that uses wrapper classes for property
values I think the change in behavior is going to break too many people's
applications.
Zero might be an OK default for commons release but I think Struts 1.1
should register it's own Converters with the defaults set with compatibility
in mind.
Hal
----- Original Message -----
From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
To: "Struts Developers List" <[EMAIL PROTECTED]>; "Deadman, Hal"
<[EMAIL PROTECTED]>
Sent: Saturday, April 06, 2002 8: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.)
>
> 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]>
