Re: [beanutils] some ideas

[robert burrell donkin]

the difficult bit is working out the right abstraction for the strategy. 
due to backwards compatibility issues, we'd want to get it right before 
beanutils is released again. but this is actually a more general issue 
which applies to all the new beans.

- robert

On Monday, September 29, 2003, at 01:44 PM, Sgarlata Matt wrote:

This sounds like a good approach.  I would like to volunteer to write the
adapters between [convert] and [beanutils].
Matt
----- Original Message -----
From: "robert burrell donkin" <[EMAIL PROTECTED]>
To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]>
Sent: Monday, September 29, 2003 6:19 AM
Subject: Re: [beanutils] some ideas

+1

my preferred solution would be to create a sophisticated conversion
component starting with new backwards compatibility issues and make the
conversion in beanutils pluggable. beanutils is going to need an
'optional'
  package to allow additional non-core dependencies sooner or later. i'd
advocate shipping an adapter in there rather than extending the core
dependencies of beanutils.
- robert

On Sunday, September 28, 2003, at 10:32 PM, Stephen Colebourne wrote:

So why don't we create a [convert] in the sandbox to play with the ideas
here? (Maybe its a lack of hours in the day....)
Stephen
----- Original Message -----
From: "Henri Yandell" <[EMAIL PROTECTED]>
On Sun, 28 Sep 2003, Sgarlata Matt wrote:

Robert, thanks for pointing out that these issues have been discussed
before.  Here are the two threads I could find:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg17188.html

http://www.mail-archive.com/[EMAIL PROTECTED]/msg05085.html


Hen, let me be honest and say I'm not quite sure I understand all 
your
ideas
regarding registries, but it sounds like a different approach to the
same
problems discussed in the first thread above, right?
Yep. One of my options was to use the first one, where you have a
specialised Converter class. However this is a bit of a hack and 
really
the internals of ConvertUtils should just move from 1 dimensional to 2
dimensional. The idea I was tending towards would have ConvertUtils 
use
'ConverterSet's internally.

For the second email, Stephen and I have remakred to each other before
about the desire to get convert-utils more usable by other projects.
All, it sounds like there is interest in improving ConvertUtils.
Before
we
discuss *how* we are going to improve it, let's discuss *what* we 
want
to
improve.  From what I can tell these are the deficiencies that have
been
identified so far:
- 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'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.

Can anyone think of any others?
Need lots more in the way of standard converters. Not all standard
converters need be defaults.
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.

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? :
)
Hen

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]