[BeanUtils-Patch] DynaProperty and BasicDynaBean patches

[Alfonso da Silva <al...@e-milio.com>]

Hi!

I include DynaProperty and BasicDynaBean patches.

I've removed the keyType attribute in the DynaProperty class and I've
modified the set(String,int,Object) and set(String,String,Object)
methods: Now, if the DynaProperty's contentType attribute isn's null,
they verify if the class value is compatible with the contentType.


Alf.


El Mon, 25 Aug 2003 22:16:41 +0100 robert burrell donkin escribi�:

> On Friday, August 22, 2003, at 01:05 PM, Alfonso da Silva wrote:
> 
> > Hi!
> 
> hi Alfonso
> 
> > I have two doubts:
> >
> > 1) The present implementation of DynaProperty allows Maps with keys of
> > any class. However, the defici�n of DynaBean only allows String keys.
> >
> > I believe that he is better to modify DynaProperty to adapt it, although
> > also exists the possibility of extending the DynaBean interface with:
> >
> >  -java.lang.Object get(java.lang.String name, java.lang.Object key)
> >
> >  -void set(java.lang.String name, java.lang.Object key,
> java.lang.Object 
> > value)
> >
> > But it can cause many problems of compatibility!!!!
> >
> > If everything is ok, I will modify DynaProperty (and I will
> generate diff 
> > ;) ).
> 
> you're correct that the DynaBean interface only allows stringy keys.
> since 
> it's an interface it'll have to start that way (it cannot be modified 
> without breaking compatibility).
> 
> i think it's probably ok to (quickly) remove the key type (at least, i 
> think that this is what you're suggesting) unless anyone else can
> think of 
> a reason why it might be useful.
> 
> > 2) It would be necessary to modify BasicDynaBean to use the new
> > functionalities of DynaProperty (if they are implemented, because they
> > are optional) or is better to create another implementation of Dynabean
> > that uses them?
> 
> i'm not how you propose to adapt this class to support this feature. if 
> you feel like contributing a patch i'll understand a little better and be 
> able to determine whether it's better to create new classes or patch old.
> 
> - robert
> 
> 


--
Mensaje enviado desde http://www.e-milio.com

Re: [BeanUtils-Patch] DynaProperty and BasicDynaBean patches

[robert burrell donkin <ro...@blueyonder.co.uk>]

hi

i've committed your DynaProperty patch (many thanks) and i like the look 
of your BasicDynaBean patch. it doesn't have any unit tests, though - and 
it's important that every new piece of functionality has these. would you 
mind creating a patch (probably for BasicDynaBeanTestCase) which tests the 
basic functionality you've added (for maps and lists, positive and 
negative)?

TIA

- robert

On Tuesday, August 26, 2003, at 12:42 PM, Alfonso da Silva wrote:

> Hi!
>
> I include DynaProperty and BasicDynaBean patches.
>
> I've removed the keyType attribute in the DynaProperty class and I've
> modified the set(String,int,Object) and set(String,String,Object)
> methods: Now, if the DynaProperty's contentType attribute isn's null,
> they verify if the class value is compatible with the contentType.
>
>
> Alf.
>
>
> El Mon, 25 Aug 2003 22:16:41 +0100 robert burrell donkin escribió:
>
>> On Friday, August 22, 2003, at 01:05 PM, Alfonso da Silva wrote:
>>
>>> Hi!
>>
>> hi Alfonso
>>
>>> I have two doubts:
>>>
>>> 1) The present implementation of DynaProperty allows Maps with keys of
>>> any class. However, the defición of DynaBean only allows String keys.
>>>
>>> I believe that he is better to modify DynaProperty to adapt it, although
>>> also exists the possibility of extending the DynaBean interface with:
>>>
>>>  -java.lang.Object get(java.lang.String name, java.lang.Object key)
>>>
>>>  -void set(java.lang.String name, java.lang.Object key,
>> java.lang.Object
>>> value)
>>>
>>> But it can cause many problems of compatibility!!!!
>>>
>>> If everything is ok, I will modify DynaProperty (and I will
>> generate diff
>>> ;) ).
>>
>> you're correct that the DynaBean interface only allows stringy keys.
>> since
>> it's an interface it'll have to start that way (it cannot be modified
>> without breaking compatibility).
>>
>> i think it's probably ok to (quickly) remove the key type (at least, i
>> think that this is what you're suggesting) unless anyone else can
>> think of
>> a reason why it might be useful.
>>
>>> 2) It would be necessary to modify BasicDynaBean to use the new
>>> functionalities of DynaProperty (if they are implemented, because they
>>> are optional) or is better to create another implementation of Dynabean
>>> that uses them?
>>
>> i'm not how you propose to adapt this class to support this feature. if
>> you feel like contributing a patch i'll understand a little better and be
>> able to determine whether it's better to create new classes or patch old.
>>
>> - robert
>>
>>
>
>
> --
> Mensaje enviado desde http://www.e-milio.com
>