2013/8/2 Oliver Heger <oliver.he...@oliver-heger.de>
> Am 02.08.2013 02:34, schrieb James Carman:
> > Okay, totally forgot we had ConvertUtils in BeanUtils. So, since we
> > have the functionality, especially for Strings, and it's extensible,
> > we could recommend that in the Javadocs perhaps.
> >
> > That Converter API is screaming for some generics action!
>
> Just for the record and because [configuration] has already been
> mentioned in this thread:
>
> One of the next points on my todo list to get [configuration] 2.0 out is
> to rework the conversion framework. Currently, we have a big class doing
> all kinds of conversions. I am going to change this to have an
> extensible converter framework.
>
> I would really love to make use of [beanutils], however, as soon as some
> classes of another project become part of your public API, you are tight
> to this project. For instance, [configuration] 1.x depends on [lang]
> 2.x. After the major release of [lang] 3.0, we got many requests to
> update the dependency, but this was not possible in a minor release due
> to binary incompatible changes - because of the changed package
> structure in [lang] the API of [configuration] would also change.
>
OT:
Just for the record: I'd not recommend using beanutils 1.x in any
component.
I've worked on the 1.x version a while ago and I think it has a lot of
issues (from todays PoV).
I'm not even sure it makes sense to put the effort into 1.9.
Maybe it's better to reboot and go directly for 2.0. But that's a different
topic.
Benedikt
>
> Something similar can happen with [beanutils], too - work on version 2.0
> has already started.
>
> Oliver
>
> >
> > On Thu, Aug 1, 2013 at 8:23 PM, Paul Benedict <pbened...@apache.org>
> wrote:
> >> I can see that we should provide a decorator/delegate
> (CSVRecordWrapper?)
> >> that has these additional methods and defers them to Beanutils. We
> should
> >> use our other Commons project to accomplish the pluggable and
> configurable
> >> conversion. Beanutils can be an optional Maven dependency. This doesn't
> >> belong in Commons Langs, because that's where the functionality was
> before
> >> migrating to its own BeanUtils project (circa 2001ish).
> >> On Aug 1, 2013 7:06 PM, "James Carman" <ja...@carmanconsulting.com>
> wrote:
> >>
> >>> Perhaps it belongs in Commons Lang?
> >>>
> >>> Anything like this that you try to put together is going to blow up
> >>> really quickly, by the way (registering new converter types, etc.). I
> >>> don't see how having a few little helper methods in CSV is that big of
> >>> an issue, personally.
> >>>
> >>> On Thu, Aug 1, 2013 at 7:59 PM, Paul Benedict
> >>> <paulus.benedic...@gmail.com> wrote:
> >>>> You might want to think of a conversion addon package using Common
> >>>> BeanUtils. That project is skilled at conversions from String and has
> >>>> pluggable capability to customize conversion types.
> >>>> On Aug 1, 2013 6:51 PM, "Paul Benedict" <pbened...@apache.org> wrote:
> >>>>
> >>>>> None of these methods document exceptions if the conversion fails
> (eg,
> >>> not
> >>>>> an integer). Also, how strict is the conversion? Can "x" represent
> >>> boolean
> >>>>> false or is that an exception?
> >>>>> On Aug 1, 2013 9:00 AM, "Gary Gregory" <garydgreg...@gmail.com>
> wrote:
> >>>>>
> >>>>>> I would like to note this CSVRecord addition I am planning on:
> >>>>>>
> >>>>>> public Boolean getBoolean(String name) {
> >>>>>> public boolean getBooleanPrimitive(String name)
> >>>>>>
> >>>>>> The method listings are at the end of this message.
> >>>>>>
> >>>>>> What I want to note here is that these are conversion methods and
> that
> >>> the
> >>>>>> record still stores the values internally as Strings. I do not want
> to
> >>>>>> Javadoc the conversion in order to give us flexibility over
> >>> representation
> >>>>>> if we decide to change it in the future (caching or whatnot).
> >>>>>>
> >>>>>> I wanted to post here in CTR mode before I or others add APIs like
> >>>>>> getLong() and getLongPrimitive(). Since this is a library, I do
> >>> believe we
> >>>>>> should end up providing such APIs at the record level for
> primitives.
> >>>>>>
> >>>>>> /**
> >>>>>> * Returns a value by name.
> >>>>>> *
> >>>>>> * @param name
> >>>>>> * the name of the column to be retrieved.
> >>>>>> * @return the column value, or {@code null} if the column name
> is
> >>> not
> >>>>>> found
> >>>>>> * @throws IllegalStateException
> >>>>>> * if no header mapping was provided
> >>>>>> * @throws IllegalArgumentException
> >>>>>> * if the record is inconsistent
> >>>>>> * @see #isConsistent()
> >>>>>> */
> >>>>>> public Boolean getBoolean(String name) {
> >>>>>> String s = this.get(name);
> >>>>>> return s != null ? Boolean.valueOf(s) : null;
> >>>>>> }
> >>>>>>
> >>>>>> /**
> >>>>>> * Returns a value by name.
> >>>>>> *
> >>>>>> * @param name
> >>>>>> * the name of the column to be retrieved.
> >>>>>> * @return the column value, or {@code false} if the column
> name is
> >>>>>> not
> >>>>>> found
> >>>>>> * @throws IllegalStateException
> >>>>>> * if no header mapping was provided
> >>>>>> * @throws IllegalArgumentException
> >>>>>> * if the record is inconsistent
> >>>>>> * @see #isConsistent()
> >>>>>> */
> >>>>>> public boolean getBooleanPrimitive(String name) {
> >>>>>> return Boolean.parseBoolean(this.get(name));
> >>>>>> }
> >>>>>>
> >>>>>> Gary
> >>>>>>
> >>>>>> --
> >>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> >>>>>> Java Persistence with Hibernate, Second Edition<
> >>>>>> http://www.manning.com/bauer3/>
> >>>>>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> >>>>>> Spring Batch in Action <http://www.manning.com/templier/>
> >>>>>> Blog: http://garygregory.wordpress.com
> >>>>>> Home: http://garygregory.com/
> >>>>>> Tweet! http://twitter.com/GaryGregory
> >>>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: 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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
