At 4:32 PM -0400 9/1/05, Laurie Harper wrote:
Rivka Shisman wrote:
Thanks Joe
When you say -
this is a limitation of the BeanUtils design model. It assumes
for any given process (instance of BeanUtils), a single conversion
strategy applies to all objects of a given type.
Do you mean that the converter applies thru my all application?
As much as I know - copyProperties() is a static method of BeanUtils so
I'm don't really know where (if at all) BeanUtils is instanciated.
Thanks
Rivka
You can register specific converters per call to copyProperties() to
get the one you need in a particular situation. Here's what I do:
BeanUtilsBean util = new BeanUtilsBean();
ConvertUtilsBean converter = util.getConvertUtils();
converter.register(myConverter, SomeType.class);
util.copyProperties(bo, vo);
That way, you can register an instance of Converter that knows what
format string to use each time you call copyProperties().
However, if you have one bean that has two properties of the same
type that will be set with strings which require different
translation strategies, you're stuck.
A counter example is how Spring approaches it; I don't have first
hand experience, but I was recently piqued by this sentence in the
Spring JavaDoc: [SpringBindingActionForm is ]"A thin Struts
ActionForm adapter that delegates to Spring's more complete and
advanced data binder and Errors object underneath the covers to bind
to POJOs and manage rejected values."
http://static.springframework.org/spring/docs/1.2.x/api/org/springframework/web/struts/SpringBindingActionForm.html
If one had access to the Spring libraries, one could extend
SpringBindingActionForm instead of Struts ActionForm -- not sure if
the Spring DataBinder knows how to deal with DynaClasses or not.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
