You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/04/07 02:08:32 UTC
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" <ha...@tallan.com>
> Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> "Deadman, Hal" <ha...@tallan.com>
> To: 'Struts Dev List' <st...@jakarta.apache.org>
> 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: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: use of pluggable converters in ConvertUtils changes Struts behavior for primitive wrapper properties
Posted by "Deadman, Hal" <ha...@tallan.com>.
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" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>; "Deadman, Hal"
<ha...@tallan.com>
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" <ha...@tallan.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> > "Deadman, Hal" <ha...@tallan.com>
> > To: 'Struts Dev List' <st...@jakarta.apache.org>
> > 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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: use of pluggable converters in ConvertUtils changes Struts behavior for primitive wrapper properties
Posted by Martin Cooper <ma...@tumbleweed.com>.
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Struts Developers List" <st...@jakarta.apache.org>; "Deadman, Hal"
<ha...@tallan.com>
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" <ha...@tallan.com>
> > Reply-To: Struts Developers List <st...@jakarta.apache.org>,
> > "Deadman, Hal" <ha...@tallan.com>
> > To: 'Struts Dev List' <st...@jakarta.apache.org>
> > 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:
<ma...@jakarta.apache.org>
> > For additional commands, e-mail:
<ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>