Design question on BeanUtils.populate()

[Steve Wilkinson <sw...@taliantsoftware.com>]

All,

In the JSP 1.2 specification there is a reference on page 75 in Table
JSP.4-2 in section JSP.4.2 about the attributes of <jsp:setProperty>.  "If a
parameter has a value of "", the corresponding property is not modified."
This is not the way I've seen BeanUtils.populate() work.  I've seen this
while using struts 1.1b1, that the empty string is set on the JavaBean.

Q.  Is this going to be changed?
Q.  Assuming above answer is no, why?

Thanks in advance,

Steve

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Design question on BeanUtils.populate()

["Craig R. McClanahan" <cr...@apache.org>]

On Wed, 25 Sep 2002, Steve Wilkinson wrote:

> Date: Wed, 25 Sep 2002 10:36:28 -0600
> From: Steve Wilkinson <sw...@taliantsoftware.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: "'commons-dev@jakarta.apache.org'" <co...@jakarta.apache.org>
> Subject: Design question on BeanUtils.populate()
>
> All,
>
> In the JSP 1.2 specification there is a reference on page 75 in Table
> JSP.4-2 in section JSP.4.2 about the attributes of <jsp:setProperty>.  "If a
> parameter has a value of "", the corresponding property is not modified."
> This is not the way I've seen BeanUtils.populate() work.  I've seen this
> while using struts 1.1b1, that the empty string is set on the JavaBean.
>

Although <jsp:setProperty> was one of the inspirations that led to the
creation of BeanUtils.populate(), I chose not to slavishly copy the JSP
semantics -- in particular the very very wierd handling of zero-length
Strings.  I found it much more useful in typical form fill-in scenarios to
deal with cases like this:
* Form is displayed with a non-zero-length string value
* User erases all the characters in the String (assumes an optional field)
* When submitted, the corresponding bean property is changed
  to a zero length String

The JSP semantics would fail to operate as expected in such a scenario

> Q.  Is this going to be changed?

I would -1 such a proposal.

> Q.  Assuming above answer is no, why?
>

Backwards compatibility.  Every Struts-based app in the world depends on
the current behavior implicitly, so changing it would break them all.

> Thanks in advance,
>
> Steve

Craig McClanahan


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>