in reply to Re^2: The Perl Review, with cheaper subscription options
in thread The Perl Review, with cheaper subscription options

That's a good idea, and that's probably what I am going to do when I get a chance to change the form. This change trickles down to other parts of the workflow too, so it's going to take a couple of days to make it happen.

I did find a manual that explains the format for every country, but it costs 600 euros. That's a bit more than I can afford, so maybe it just needs an open source project to make that sort of thing free.

The big, scary problem with free form text entries is credit card fraud, and that's my first concern with validating input. Although most people will just format the address that they already entered in the other parts, some people will want to enter a completely different address. The credit card companies consider my business "high risk" right now because I'm new and I deliver things on the internet. Shipping to addresses other than the mailing address of the credit card raises that risk in their eyes. Big companies can eat the fraudulent charges, but I can't.

Not that it matters to any customers though, and it's a problem I still want to solve. It is not wholly a technical problem though.

--
brian d foy <bdfoy@cpan.org>
  • Comment on Re^3: The Perl Review, with cheaper subscription options

Replies are listed 'Best First'.
Re^4: The Perl Review, with cheaper subscription options
by grantm (Parson) on Dec 08, 2004 at 01:20 UTC

      A useful online resource: International Mailing Address Formats.

      Perhaps it'd be useful if it were correct. A Dutch address should have "$postcode  \U$city\E", indeed with double whitespace in between.

      Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Re^4: The Perl Review, with cheaper subscription options
by Aristotle (Chancellor) on Dec 20, 2004 at 09:26 UTC

    maybe it just needs an open source project to make that sort of thing free.

    That is definitely needed. Unfortunately, it's one of those problems like dates and encodings: a twisty maze of little exceptions all alike. That's not something that lends itself to the usual open source processes. As bad luck would have it, this is also a problem that people are less likely to come across than encodings, let alone dates. It is mostly businesses which are affected. It would be great to codify this knowledge Regexp::Common style — but it will require some very dedicated people to do a lot of thankless and mostly unnoticed work before the ball gets rolling.

    Makeshifts last the longest.