[
https://issues.apache.org/jira/browse/VALIDATOR-247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12539783
]
Ben Speakmon commented on VALIDATOR-247:
----------------------------------------
It's simple, which I'm a big fan of. The only concern I have is whether
anything important is lost by treating credit cards only as validators -- will
we ever need to put them in collections, associate them with names, sort them,
etc. -- all the crap you want to use a full-fledged object for. I can't say
something like that will definitely be required, but I can't rule it out
either. I'm also wondering how easy it'll be to put JSR 303 annotations on top
of this, but if it's going to be redone again for Validator 2, then no problem.
My gut is saying that this is good enough and covers what people need today,
and that going too overboard with it is overengineering. This works, is easy to
understand, and simple to use, so I think going with it makes sense. Can you
throw together tests for it?
> Move CreditCardValidator to routines package and refactor
> ---------------------------------------------------------
>
> Key: VALIDATOR-247
> URL: https://issues.apache.org/jira/browse/VALIDATOR-247
> Project: Commons Validator
> Issue Type: Task
> Components: Routines
> Reporter: Ben Speakmon
> Assignee: Ben Speakmon
> Fix For: 1.4
>
> Attachments: CreditCardValidator.java
>
>
> Having copied CreditCardValidator to routines, it now needs to be refactored
> to use CodeValidator/LuhnCheckDigit/etc. It might also make sense to break
> CreditCardType out into a separate 1.4-style typesafe enum so it can be
> easily converted to a real enum for Validator 2.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
