BeanUtils are fantastic. There is just one minor issue
I have with them. There are no hooks for me to
augment their behavoir.
Here's my specific problem. I am using an Enum
framework that gives me very nice, fully automatic
support for Enum types like Gender{Male, Female}. It
is internationalized, easy to use etc. Each enum type
is represented by its own class, like
"com.plotix.enums.Gender". One of nice aspects of
Enums is that they lend themselves perfectly to HTML:
I am using them to populate select/option tags. With
select/option tags, I don't have the possibility of
invalid user input, so I really don't have a need to
declare String getters/setters on my ActionForm.
Those getters/setters take Gender objects. So far so
good.
The problems begin in Struts when a POST comes to
ActionServlet and ActionServlet invokes
BeanUtils.populate() to copy parameters of the POST
into the ActionForm. The conversion from String
(that's what comes in the POST) to Gender (that's the
type of the setter on the ActionBean) fails, because
BeanUtils don't know anything about my Enums, nor
would I want them to. All I want is for them to
delegate their work to a custom object that would help
them with type conversion when they discover they are
unable to perform the job on their own.
I have two specific solutions in mind:
1. We could introduce a registration mechanism for
custom type converters. BeanUtils would then invoke
these type converters one after another until it found
one that could do the job. The interface of the
converter could be something like:
public interface TypeConverter {
boolean canConvert(Class from, Class to);
Object convert(Object from, Class to)
throws ConversionException;
}
The registration mechanism could either be static
(which I don't think would be cool) or it could be
dynamic, with a registry of converters passed to
BeanUtils in the methods calls. In a web app, the
registry could be hosted by the application context,
in Struts - ActionServlet.
2. Alternatively, we could introduce some generic API
on ActionBean like: setProperty(String propertyName,
Object value). BeanUtils would call this method for
every property. I would then override this method,
do special things to my special fields and then let
the superclass do the rest. The superclass would then
call BeanUtils back. We don't want to introduce a
dependency between BeanUtils and Struts, so the
setProperty() method would have to be declared on an
interface defined in Commons. ActionForm would
implement that interface.
If this approach is accepted, I will, of course,
volunteer to do the work.
I wonder if this issue is unique to my project? Is
anybody else experiencing similar problems?
Best regards,
- Dmitri Plotnikov
[EMAIL PROTECTED]
__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/
