commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From robert burrell donkin <>
Subject Re: [betwixt] BeanReader - setXXX(Object)
Date Wed, 09 Apr 2003 16:55:16 GMT
hi Brian

the way i see it is that betwixt handles only beans and primitives at the 
moment. there are other stuff which aren't primitives and which aren't 
beans but which are commonly going to be present when you deal with beans.
  for example, java.util.Date's.

i think that the most common use case is that these will be mapped to 
CDATA. for example, a Date <-> <value>20011104</value>. so what's needed

is customizable string <-> object conversion. BeanUtils already has a nice 
solution for this kind of thing and i'd probably want to leverage this to 
allow customization of the mapping for particular types (rather than what 
you were proposing).

i don't think that it'll be too difficult to implement but you're right 
that the dev list is the best place to discuss matters like this. 
hopefully you're join us there.

- robert

On Monday, April 7, 2003, at 05:58 PM, Brian K. Wallace wrote:

> Robert -
>   I pulled down the betwixt code and after a bit of nosing around, came to
>   the same conclusion... for better or worse. (better that I didn't come
>   to the wrong one, worse that I posted before looking thoroughly I gues)
> .
>   I know there are other instances for Objects that aren't beans - and in
>   the interest of solving my own issues for the interim, wrote a hack into
>   my BeanRuleSet (bad - I know, but it works for now) that accomodates
>   Integer and BigDecimals (the ones I need at present) so I'd be very
>   interested to hear the outcome of this issue (hmmm... dev list maybe? :
> )
>   ).  I also noticed the 'className' attribute which I found helpful (had 
> to
>   make a mod for Object == String on this one... bad again, but hey)...
>   but odd. While I understand the usefulness of being able to tell the
>   reader exactly what class to use, would it not make more sense to create
>   a 'mapName' attribute basically telling the reader "use whatever you
>   have mapped to 'MyObject'"? It may be great for internal Java processes
>   to go directly to class 'MyObject', but when the 'writer' of the XML
>   isn't java, may not even be local or know the recipient's package layout
>   and class names, why bother requiring a className to be known. All that
>   said, I wouldn't want to see 'className' removed entirely... just "if
>   (mapName != null) use map; else if (className != null) use class;".  I
>   know this applies more to the dreaded "Object" environment... but it's
>   nice to have classes that are more generic sometimes. My 2 cents, I
>   guess... both from a 'user' and a 'developer'.
>   Thanks again for the response, tho'.
> Brian
>> hi brian
>> i'm pretty sure that this is because betwixt uses the property
>> signature  to guess the type of object you want to create. so betwixt
>> thinks that you  want an object of Object type to be created.
>> there is an added complication with using an Integer object - and
>> that's  because it's not a bean. you need to pass in the information in
>> the  constructor rather calling setters.
>> having said that, i have some ideas about how to support this kind of
>> thing which i'll raise on the dev list and see what people think.
>> - robert
>> On Friday, April 4, 2003, at 05:55 AM, Brian K. Wallace wrote:
>>>   I was wondering if there is something I'm missing, or if Betwixt
>>>   just can't do it as is. Given the following XML:
>>> <Element>
>>>   <name>Element 1</name>
>>>   <value>
>>>     <Integer>5</Integer
>>>   </value>
>>> </Element>
>>> and the following bean mapped to the "Element" XML element:
>>> public class ElementBean {
>>>   private String mName;
>>>   private Object mValue;
>>>   public ElementBean() {
>>>   }
>>>   public void setName(String iName) {
>>>     mName = iName;
>>>   }
>>>   public String getName() {
>>>     return mName;
>>>   }
>>>   public void setValue(Object iValue) {
>>>     mValue = iValue;
>>>   }
>>>   public Object getValue() {
>>>     return mValue;
>>>   }
>>> }
>>> Is there any way to get the value (5) into the Element's setValue
>>> method as an Integer as opposed to an Object?  I rely on being able to
>>> reuse objects and pulling out the values as appropriate, but with the
>>> BeanReader, all calls to 'getValue' result in Object@....
>>> Aside from my 'Object'ion, the reader parses fine. Any help would be
>>> appreciated.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: For
>> additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message