Zend_Validate is a component of Zend Framework which provides validation classes which out-of-the-box enable you to check from string lengths to stranger properties like conformance to regular expressions or to a standard for barcodes. [...] Some parts of Zend_Validate are quite complex, and tie-in with the other components: there are file-related validations on size, hash and more to attach to your forms; in the domain-specific category instead, we can find validator for credit card numbers consistency, or barcodes; isbn codes; and more...

He includes a code sample to show of just some of the validators the component includes like: alpha-numeric, "between", valid email address, valid IP address, matches a regular expression and, a very handy feature of the component, setting up chains of validations.

It's easy enough to add a filter to remove the space, but I'm a little worried that when (and if) it gets fixed, will the fixed version Zend_Validate_PostCode then fail to validate postcodes without the space? In theory it should as the space is part of the spec. I'd hate my code to unexpectedly break due to a valid bug fix. I can easy work around this worry though by simply creating my own extension of Zend_Validate_PostCode.

The thirty-five line code example allows you to correctly validate the postal code with a quick call to the "isValid" method. He also links to another method from Paul Court to handle things similarly.

The basic usage of Zend_Filter_Input is [a simple call to Zend_Filter_Input with the filter types and data to filter]. The problem is that the message you get out isn't always written as you would like. Consider the output if the body record is empty. The text isn't exactly what I would want to display to a user. To change it you pass in a messages parameter to the $validators array.

There's a long list of these "messages parameters" and Rob includes them in the post - things like NOT_ALNUM, CHECKSUM, QUOTED_STRING, INVALID_DASH and UNDECIPHERABLE_TLD (37 of them in all).