commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <robertburrelldon...@blueyonder.co.uk>
Subject Re: Design question on BeanUtils.populate()
Date Thu, 26 Sep 2002 18:11:03 GMT
i suppose that we could add another method which behaves as per the jsp 
spec. should be pretty simple to write (just remove parameters from the 
map). i don't know structs well enough to know whether this would be 
useful or not.

- robert

On Thursday, September 26, 2002, at 03:43 AM, Craig R. McClanahan wrote:

>
>
> On Wed, 25 Sep 2002, Scott Sanders wrote:
>
>> Date: Wed, 25 Sep 2002 19:41:53 -0700
>> From: Scott Sanders <ssanders@nextance.com>
>> Reply-To: Jakarta Commons Developers List <commons-
>> dev@jakarta.apache.org>
>> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
>> Subject: RE: Design question on BeanUtils.populate()
>>
>>> 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.
>>>
>>
>> I would also tend to agree.  The jsp: semantic is brain dead.  Sun, can
>> you hear this? :)
>>
>
> Of course ... but it's too late to change that semantic as well, for the
> same reason :-).
>
> Craig
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.
> org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.
> org>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message