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
>
>
