Sorry to interject...
>From personal experience I would recommend coming up with a custom
solution in this case. I've built an entire GUI framework partially
around PropertyEditors and their short-comings are numerous. For
simple data conversion I think they are overkill.
PropertyEdiors are designed to be used by taking the value out of
the bean, editing it, and then asking the property editor for the
value so you can put it back into the bean... or alternately,
registering a PropertyChangeListener to watch the value change. This
seems a bit heavy for just data conversion and in a transactional
environment all/most of the other features of PropertyEditors are
wasted.
Something like a filtering/conversion layer seems more appropriate.
I've usually put conversions like this in the validation layer, but
I'm not sure how that would fit in struts.
Just my $0.02,
-Paul Speed
"Craig R. McClanahan" wrote:
>
> 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/
> >
