Just a few minutes ago I read Jamie Nay’s A Better Postal/Zip Code Validation Method for CakePHP 1.2 blog post.
Jamie says that “The Validation::postal() method that comes with CakePHP 1.2 is good in that it can handle a number of different country formats, but the problem is you can only validate your data against one country. What if you want to accept, say, either Canadian or US postal/zip code formats? I ran into this problem earlier today, and decided to write my own postal() function that can take either a string as the country, just like Validation::postal(), or an array of countries.”
I’m probably going to have to wait for Jamie to wake up before my comment on that blog-post is approved, but the crux of it is “Don’t”. Don’t write your own code to validate user input, unless of course the input data is specific to a problem domain that others haven’t catered for yet.
I drew attention to two things. The first is that there are Validation packages in PEAR, including the main Validate class and all the Validate_xx subclasses such as Validate_US, Validate_CA and some 22 others).
The second item I drew Jamie’s attention to is that his validation code counts a zip code of “00000″ as valid, when the USPS zip code look up tool correctly (and they should know!) identifies that code as invalid.
Why spend time writing and debugging regular expressions, compiling lists of valid data and so on when other people have already done this work? Especially when it comes down to such things as validating data input which is crucial when you need to guard against cross site scripting vulnerabilities.
Focus on what you need to do rather than reimplementing what others have already done.
Honestly, this probably should be subtitled – “Stop the NIH craziness, please” – though to be fair Jamie might not have known of the solutions already out there.
Hear, hear. The massive amount of detail work donated by the diligent and progressive user community should not be ignored lightly.
Adding a new Validate_XX package to PEAR is not a huge undetaking, either. It stands a better chance of surviving in the long term than a one-person validator script.
Thanks for the response, Ken. I agree that a validation solution such as the PEAR validation packages would be a good, robust choice, and probably better than the solution I put forward.
However, as the subject and content of my post indicated, I was addressing a deficiency with the CakePHP framework’s postal validation code. So, my solution is based on the existing Validation::postal() method that comes with CakePHP. The regular expressions are taken from that method. So, while PEAR is a good solution, it was beyond the scope of my article to suggest scrapping Cake’s entire Validation class in favour of another library.
So, I didn’t “spend time writing and debugging regular expressions, compiling lists of valid data and so on” – you can thank the CakePHP team for that. I simply built upon their work.
And, Ollie – I’m not “ignoring lightly” the “massive amount of detail work donated by the diligent and progressive user community”. I’m part of the equally diligent and progressive CakePHP user community, so I’m building on that.
Anyway, thanks for the response Ken – it did give me something to think about. If I had the time I would consider replacing Cake’s Validation class with a more robust suite, but it’s just not in the cards right now.
[...] response to a different post he read on a postal/zip code validation topic, Ken Guest has points out other resources that can be used to accomplish the same sort of thing and already exist. I drew attention to two [...]
Except that sometimes you don’t want or need PEAR.. I haven’t used PEAR for a long time because the interface kept changing with every minor version upgrade..
The quality per package seems to vary a lot… and sometimes the project owner seem to have abandon the project. Not to mention that most hosts do not have PEAR installed..
It is not without a reason most frameworks come with their own solutions… even ZEND ^^
http://framework.zend.com/manual/en/zend.validate.html
Validation should be a part of any framework to my opinion
@Jamie: That’s fair enough – often one must work within the confines of what has already been decided on. You could, I suppose, check if the relevant PEAR packages are installed and if so delegate the validation tasks to those packages.
@Chris: chances are the PEAR packages you had been using were not stable releases – once a package has been released as stable it must remain backwards compatible in every future release.
Also it is very easy to set up individual PEAR installs in common hosting environments; steps required for doing this are detailed at http://pear.php.net/manual/en/installation.shared.php and are also useful for situations where you perhaps do not have permission/access rights to update or install new packages to an existing PEAR install on a certain machine.
Regarding abandoned projects – it is true that there are a number of orphaned packages in PEAR – in fact a list of them is available at http://pear.php.net/qa/packages_orphan.php – the PEAR Group and QA teams adopted a mechanism for other developers to assist in maintaining those packages and potentially take over responsibility for them. This is outlined at http://pear.php.net/manual/en/newmaint.takingover.php
PEAR itself is, I think, framework agnostic; it certainly isn’t what some would term a full-stack framework such as Symfony, CodeIgnitor or CakePHP; it is PHP’s equivalent to Perl’s CPAN (http://www.cpan.org/ ), Ruby’s gems ( http://docs.rubygems.org/ ), and Python’s eggs ( http://www.python-eggs.org/ ).
(It is also an install mechanism – popular and reliable enough for many frameworks to be installable via the PEAR installer; solar, zend, symfony are just a few that can be downloaded and installed via PEAR.)
This actually leaves plenty of room for PEAR packages to do some of the grunt work required by various frameworks and also gives the benefit of only having to fix a certain bug once – rather than having to solve/fix them a multitude of times depending on what framework you’ve used for the project in hand.
Fix a bug, send the patch upstream and never have to worry about it again – sounds good, eh?
Nice to see someone thought of this already.