Hi Dmitri,
No, I don't think that your problem is unique -- but it's definitely one I
haven't had time to think much about in a Struts 1.0 time frame.
In addition to the two alternatives you have proposed, the JavaBeans spec
provides a standard API for doing custom type conversions -- the
PropertyEditor class, where you end up calling the getAsText() and
setAsText() methods to do the conversion. Would it be helpful to you if
the conversion utilities supported that mechanism automatically?
Even if we do, that wouldn't necessarily preclude building our own
conversion registration system in addition -- but I like to support the
standard mechanisms when they are available.
Craig
On Fri, 11 May 2001, Dmitri Plotnikov wrote:
> 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/
>
