I'll have to look into what Beanutils requires since it's been sometime I last directly dealt with it. I think it comes with basic Java conversions but everything can be configured as needed.
I did not know about Commons Convert. Why "two" commons project that do the same thing? Paul On Sat, Aug 3, 2013 at 11:25 AM, Adrian Crum < adrian.c...@sandglass-software.com> wrote: > Actually, I picture it like this: Commons CSV does not contain any > conversions, and data type conversions are left to the application > developer. We can recommend Commons Convert. The applications developer is > free to create any wrappers/facades necessary to connect the two. > > -Adrian > > > On 8/3/2013 9:18 AM, Paul Benedict wrote: > >> Adrian, the conversions would be configurable. At least that's how I >> envisioned it using existing BeanUtils functionality. Gary has a request >> our to me to demo that. >> On Aug 3, 2013 11:10 AM, "Adrian Crum" <adrian.crum@sandglass-** >> software.com <adrian.c...@sandglass-software.com>> >> wrote: >> >> Inline... >>> >>> On 8/3/2013 9:05 AM, Gary Gregory wrote: >>> >>> On Sat, Aug 3, 2013 at 11:50 AM, Adrian Crum < >>>> adrian.crum@sandglass-**softwa**re.com <http://software.com> < >>>> adrian.crum@sandglass-**software.com<adrian.c...@sandglass-software.com> >>>> >> >>>> >>>> wrote: >>>> >>>> Have you considered recommending Commons Convert? >>>> >>>>> No: it is unreleased. Are you willing to help polish it to 1.0? >>>>> >>>> Aside from a pending bug fix, the code is complete. The project has been >>> used by Apache OFBiz for years, so it is proven and stable. So, I don't >>> know what additional steps are required to polish it. Having an official >>> release would be wonderful. >>> >>> >>> >>> Yes: I'd like to eat our own dog food. >>>> >>>> Gary >>>> >>>> I agree that Java data type conversion is outside the scope of CSV. >>>> >>>>> What about a CSVRecord wrapper that delegates to [convert]? >>>>> >>>> What would that look like? From my experience, hard-coding conversions >>> is >>> not scalable. If an application needs to convert a CSV field to a custom >>> type Foo, how will the wrapper accommodate that? >>> >>> >>> >>> Gary >>>> >>>> >>>> -Adrian >>>> >>>>> >>>>> On 8/3/2013 8:36 AM, Gary Gregory wrote: >>>>> >>>>> Hi All: >>>>> >>>>>> I recently added these CSVRecord APIs: getBoolean(String), >>>>>> getInt(String), >>>>>> getLong(String), getBigInteger(String). >>>>>> >>>>>> Some people are OK with this, some consider this out of scope, some >>>>>> consider it not necessary for 1.0, some -1, some are worried about >>>>>> feature >>>>>> creep (default values, Calendar, Date, List, and so on), some think >>>>>> the >>>>>> Javadoc should be clearer. >>>>>> >>>>>> At the very least I think we should document how to access or convert >>>>>> typed >>>>>> values. We could: >>>>>> >>>>>> - Document the new APIs, or remove them AND: >>>>>> - Document how to use another Commons API >>>>>> - Document how to use another (non Commons) API >>>>>> - Document how to do it all yourself >>>>>> - Create a CSVRecrord wrapper class that contains all the APIs where >>>>>> the >>>>>> implementation may or may not delegate to another Commons API. >>>>>> >>>>>> No matter what, it's pretty obvious that this conversion code is going >>>>>> to >>>>>> exist somewhere, in the user's app, in [csv] or someplace else. >>>>>> >>>>>> We should make a plan such that if we do not provide this feature in >>>>>> 1.0, >>>>>> we have a roadmap for our users. >>>>>> >>>>>> Gary >>>>>> >>>>>> >>>>>> ------------------------------******--------------------------** >>>>>> --** >>>>>> >>>>> --**--------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.****apac**he.org< >>>>> http://apache.org**> >>>>> <dev-unsubscribe@**commons.**apache.org <http://commons.apache.org>< >>>>> dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>>>> > >>>>> >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>>> >>>>> >>>>> ------------------------------****----------------------------** >>> --**--------- >>> To unsubscribe, e-mail: >>> dev-unsubscribe@commons.**apac**he.org<http://apache.org> >>> <dev-unsubscribe@**commons.apache.org<dev-unsubscr...@commons.apache.org> >>> > >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > dev-unsubscribe@commons.**apache.org<dev-unsubscr...@commons.apache.org> > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Cheers, Paul
