From: "Craig R. McClanahan" <[EMAIL PROTECTED]> > On Thu, 30 May 2002, James Strachan wrote: > > > From: James Strachan <[EMAIL PROTECTED]> > > > > I'd really like it if the set(String name, Object value) method on the > > WrapDynaBean would convert Strings to primitive types automatically. Without > > this conversion its possible to get a strange exception saying that a "write > > property does not exist", when really the issue is that a String was passed > > into a numeric/boolean property by accident. > > > > Now I could implement this behaviour by implementing a derivation of > > WrapDynaBean, say called ConvertingWrapDynaBean (bit of a mouthful). Though > > I'd far more prefer the default behaviour of WrapDynaBean to be able to do > > primitive type conversions. Afterall the great strength of using dyna beans > > is they can be used generically and work nicely in servlet / XML style > > environments where things are mostly text. > > > > Its a fairly trivial change; rather than calling > > PropertyUtils.setSimpleProperty(bean, propertyName, value) we can call the > > (now public) BeanUtils.setProperty(bean, propertyName, value) which does > > type conversions. > > > > I've already got a patch for this which I'll commit if folks agree. Does > > this sound reasonable? > > > > While it sounds like a very useful mechanism, I've got three concerns > about modifying WrapDynaBean to do this: > > * Consistency with standard JavaBeans - property setters here have > no support for conversion; you have to do it ahead of time
DynaBean isn't a standard JavaBean so I'm not sure this applies. In this case the DynaBean is a facade over the real bean, in much the same way as the static BeanUtils methods are, so we can change behaviour if we wish. > * Inconsistency between setter (with conversion) and getter (without) I don't see that as a big deal. The value passed into a setter method may be quite different to what the getter returns anyways, the bean can do what it likes. Though in this particular case, the type that the getter returns may be different from the type that the setter accepts. > * Performance - The BeanUtils.setProperty() method will take longer in all > of the cases where conversion is NOT required. Already there is quite a large performance hit by using BeanUtils.populate() and BeanUtils.setProperty() due to all the checking for indexed properties & mapped properties using String.indexOf and the like, which far outweight testing the value is of the correct type which is a fairly lightweight overhead. So eventually it'd be nice to not use these methods in a converting WrapDynaBean instance. > I'd be +1 for something like ConvertingWrapDynaBean for people that want > behaves this way, but don't really like the idea of modifying the existing > functionality (since it's now been released). It shouldn't break any existing code; unless folks are relying on the exception that a 'property does not exist' when it does really, its just of a different type under the covers. I don't mind too much either way, I was mostly being devil's advocate above. I just think ConvertingWrapDynaBean is a bit of a mouthful of a class name ;-). So for now lets err on the side of caution and add this functionality as a WrapDynaBean derivation. Until we can think of a better name I'll add a ConvertingWrapDynaBean implementation to CVS shortly... James _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
