Sgarlata Matt wrote:
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Sunday, September 28, 2003 4:43 PM
Subject: Re: [beanutils] some ideas
- Converters must be registered for each type, and subtypes do not
inherit
converters. In one of the threads above someone mentioned this is
particular a problem when dealing with Enumerations.
Yep. One of the problems here is how to define the inheritence lookup
policy. Effectively we have the multiple inheritence problem.
I suggest we adopt a simple solution: the match is determined by the order
in which converters are registered. However, perhaps we should define a Go4
Strategy of which this is only one pluggable implementation.
An alternative (and one we'll likely end up with for finding appropriate
Converters in JavaServer Faces) is to first look for an exact match
(i.e. a Converter registered for this exact class); if not found, then
walk up the inheritance hierarchy until you find one. You have to
decide how to order the lookup for parent classes versus interfaces
implemented by those classes, but it probably doesn't matter much as
long as the algorithm is well defined.
I've a ClassMap class that I use for these kinds of things, but it imposes
a certain lookup policy and is not generic.
- (I'm not as sure about this) ConvertUtils only allows a single set of
conversion rules to exist, since it is a static class. It would be good
if
different conversions could be defined for different circumstances.
Kind of. If you dig into the code enough, you can lug ConvertUtilsBeans
and ConvertUtils around a bit I think, but it doesn't look like a simple,
easy to do piece of code. It needs to be much easier.
I figured the indirection to a non-static Bean was done for some reason, I
just hadn't finished thinking it through :)
Can anyone think of any others?
Need lots more in the way of standard converters. Not all standard
converters need be defaults.
FormatConverter is an obvious one to include, it taking a java.text.Format
in its constructor.
Need a wrapper for convert utils that provides a configuration system so
people are not always building their own structures. This should not be
mandatory however.
What would such a system be used for? You mean something more sophisticated
than the ConvertUtils.register method? What would it do?
Needs to still fit BeanUtils' needs.
Collection converters need to support internal Converters. ie) might want
to turn an ArrayList of Person into an ArrayList of String. Perhaps? :)
Very cool! I expect we could do this for any Collection and for Arrays as
well.
Hen
Matt
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
