Thomas' implementation is amazing for being so small, but a little
naïve - it only detects a small set of credit card types. A fairly
obvious trade-off when you're limit is 140 bytes, but if I implement
it I might like something a bit more rounded.
I may be harping on about it here, but I do quite like the
dojox.validate implementation[0] but even that doesn't cover all the
cards I'd like (it does include a check against the Luhn algorithm,
and makes adding new card types very straightforward.
What I really to get right is the return values, and to think about
how that fits with my API. A simple implementation would look like
this:
var isCard = Validator.isValidCreditCard(someValue); // returns
boolean
But this doesn't give you any way of getting the type of credit card.
Another option would be to mirror the ".errors" property with some
kind of ".responses" one, which would include a value per validation
run:
myValidator.add('isValidCreditCard');
myValidator.add('minLength', 1);
myValidator.validate(visaNumber);
console.log(myValidator.errors); // empty array
console.log(myValidator.responses); // [true, 'visa'];
myValidator.responses would contain one value for each validation. A
simple boolean (passed / failed) in most cases, but some other value
if a return was actually required. This seems a bit sucky, since
you'd have to track which validations you added in what order.
It could be an object with the keys being the same as the names of
validations, but then you couldn't have multiple validations of the
same type (like matchesRegex()).
I guess it could be an array per type, which is sort of alright,
except you still end up needing to track what order you added the
validations.
Probably better would be a chained method like "message()" .. maybe
called "callback()". That would let you supply a function that would
be called with a boolean and a "response":
myValidator.add('isValidCreditCard').callback(function(passed,
cardType) {});
I'll have a think about it and start a branch if I get any time!
Pete
[0] https://github.com/dojo/dojox/blob/master/validate/creditCard.js
On Aug 16, 5:02 pm, Ben Barber <[email protected]> wrote:
> On Tue, Aug 16, 2011 at 10:16 AM, Scott Elcomb <[email protected]> wrote:
> > On Mon, Aug 15, 2011 at 4:19 PM, Pete Otaqui <[email protected]> wrote:
> > > As I get time, I'll be addressing the following points:
>
> > ...
> > > * add more validation routines ... numberFormat is favourite and
> > > although credit card number validation is in may ways desirable, I
> > > think that it's complicated to do well, and probably more useful in a
> > > very client-side focused library so I might leave that for a while
>
> > This is not a complete solution but you may find it useful when
> > looking to validate Credit Card numbers:
>
> > <http://en.wikipedia.org/wiki/Luhn_algorithm>
>
> > There's a link to a JavaScript version (under 'Other Implementations')
> > that's worth a peek at.
>
> Thomas Fuchs contributed 140byt.es entries for both the Luhn 10 algorithm
> and credit card type detection. Both are MIT licensed and under 140 bytes.
>
> Luhn 10: <https://gist.github.com/976805>
> CC Type Detection: <https://gist.github.com/978597>
> 140byt.es: <https://gist.github.com/962807>, <http://140byt.es>
>
> Ben Barber
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
