String-Object Mapping and Re: Re: [CSV] How to start?

[sp...@aformatik.de]

Hi all, hi Hen,

thank you Hen for your fast reply.

> My first thought is that String->Object mapping is something
> that comes up a lot. We had a Commons Convert sandbox project
> a while back, but it was overmodelled.
> Now Morph (spawned out of the Convert discussions) is
> interested in joining, and of course BeanUtils still
> has conversion code in (this is what lead to the Convert
> component).

You are right, a String->Object mapping is the base and should be
generalized. I did not found Morph, would you please give me the link. In
BeanUtils I have found the ClassConverter, with my fist look I can't see
the useness. Is this the right class?

My String-Object Mapping is done by an array of small adapters. These
implement a small interface and set the string with the concrete object
setMethod or gets the String with the right getMethod. I think this is
small and normal java. I do not use reflections. I did not found this since
now.

I would like to discuss this concept. As I see now, the CSV Project would
have following steps:
1. discussing the general String-Object Mapper
2. implementing the CSV on top of this
3. enhancing the CSV with various types of csv-formats

> So my assumption (architectually) for a CSV-Object mapper would
> be to hook a csv parser up to Morph. I've not tried that, so
> I might be missing lots.

I agree, if Morph is a good solution. The String-Object Mapper is just a
tiny solution and should be. I see here only two convenience methods and a
small interface. The client code create normaly small anonymous inner
classes and parse them in form of an array as parameter.

> The best way to keep discussion going is to put your code
> online somewhere so everyone can look at it.

That is a good idea, I will do this in the near future.

Bye Sebastian