Learning Flex – Lesson 14, Using Formatters and Validators

Flex has formatter classes that can be used to format raw data into customized strings. You can combine these with data binding to be able to format multiple fields simultaneously. All formatters are subclasses of the Formatter class and built in versions include:

CurrencyFormatter, DateFormatter, NumberFormatter, PhoneFormatter, ZipCodeFormatter.

Each formatter has properties related to it’s type so a CurrencyFormatter has currencySymbol and precision properties and a PhoneFormatter has an areaCode property (area code to add to a 7 digit number, -1 means do not add and is the default). They all have pretty sensible defaults and more data can be found in the Adobe referenceĀ docs. To use a defined formatter, just call it’s format() method providing the value to be formatted.

All validators are a subclass of the Validator class. The following are provided validators but you may define your own:

CreditCardValidator, DateValidator, EmailValidator, NumberValidator, PhoneNumberValidator, SocialSecurityValidator, StringValidator, ZipCodeValidator.

All validators have a source attribute which is the id of the control that is being validated and defines where any error message will appear on failure. The property attribute defines where the actual information being validated is stored (ie if we’re validating a TextBox called myText, the source would be myText and the property would be text). If the validation fails, the control is highlighted in red and hovering over it produces an error message.

Like formatters, validators can have properties related to it’s type so a ZipCodeValidator has a domain property (which can be “US Only“, “US or Canada” or “Canada Only“) and a CreditCardValidator requires source and property attributes for cardType and cardNumber.

By default, the validator listens for the ValueCommit event on the source component which corresponds to when the user leaves that component. You can change this behavior or call the validate() method to force validation.

Often, just detecting the validation error is not enough, you want to prevent the user from proceeding until they fix the error. In this case, you need to listen for the ValidationResultEvent (calling validate() directly will return an object of this class). The event type property will either be VALID or INVALID.

Regular Expressions

Regular expressions can be used to help design custom validators. These are special strings that define a pattern a client string should match. You can find out more about defining regular expressions here.

The RegExp class allows you to define a regular expression string using it’s constructor via new which has a second optional parameter for flags (i=case insensitive, x=white space ignored etc). Alternatively you can define a literal expression directly for a RegExp variable. In this case you don’t need to escape the ‘/’ character (because you’re not providing it as a string) but you do need to put one at the start and end of the pattern – traditional regex style (any flags would go after the second /).

To execute the regex, use the search() method of the String object you are checking, passing the RegExp object you’ve created. This will return -1 if there is no match for the pattern (or the position in the string where the pattern begins).

You can build a custom validator by extending mx.Validators.Validator. Call the super() method from the constructor and override the protected method doValidation(value:Object):Array. The doValidation() method returns an Array of ValidationResult objects. Start by clearing your results Array then call the super class version of the method (super.doValidation()). If the input value object is not null, call it’s search() method providing your RegExp. If it’s not found, call the push() method on the results Array object to add a new ValidationResult object. This should specify the properties isError:Booleantrue if there’s an error, subField:String – the name of the subfield (if any) the error is associated with, errorCode:String – the error code for the problem (eg “notNumber”) and the errorMessage:String – a longer, more descriptive error message (eg “account ids cannot contain letters, they are 7 digits long”).

You can set the required property on a validator to true to ensure that if the field is left blank, it fails validation. You’ll need to call the validate() method directly for this at a point you know the user “should” have entered the data (eg on a submit button click).