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:
Each formatter has properties related to it’s type so a
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:
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
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
property attributes for
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
validate() directly will return an object of this class). The event type property will either be
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.
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() method returns an
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
true 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).