The OFBiz community wanted to spin off the conversion framework to a
separate project. I found the abandoned Commons Convert project and
moved the code there.
Someone suggested using Commons Convert for BeanUtils - so the
duplication can be eliminated.
-Adrian
On 8/3/2013 9:42 AM, Paul Benedict wrote:
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
