X

It's All About the Platform.

Common Regular Expression Patterns

Guest Author

Introduction

Regular Expressions are a powerful way to perform automated string matching. This post goes through some common use cases that can be used in Application Composer.

Regular Expression Examples

Regular Expressions are useful to validate user input forms after a form has been submitted. Email addresses, passwords, telephone numbers, zip/post codes and checking for inadvertent HTML tags are all good candidates for form validation using Regular Expressions.

Each of the above use cases are listed in the table below along with possible regular expression string patterns. It's important to note that the following are starting points and can be tweaked to be more restrictive based on requirements.

 

Pattern Type Example String Regex Pattern
Email Address
somebody@someplace.
somedomain
^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\\.[a-zA-Z]{2,4}$
Telephone Number
+1 289 8998 0098
^\+(?:[0-9] ?){6,14}[0-9]$
US Zip Code
NNNNN
(optionally NNNNN-NNNN)
^\\b\\d{5}\\b(?:[- ]{1}\\d{4})?$
Password
SGhowk!E
^[a-zA-Z]\w{3,14}$

 

 

Regular Expression Detail

When using regular expressions in Application Composer, patterns should be assigned to a string value that is enclosed using forward slashes. Using quotes doesn't work with Regular Expressions. Please see this blog post for further information.

The email address pattern will check for known valid characters, the at symbol and then a domain name. The last section of the email address being at least two characters but no more than four. This would match where email addresses end with .com or .co.uk and most other common email address domains around the world. However .somedomain would not work because somedomain is longer than four characters.

The telephone address pattern matches a telephone number that begins with a plus symbol and contains between 6 and 14 numbers.

The US Zip Code pattern checks that a zip code contains a group of five numbers or two groups of numbers the first with five numbers and the second with four numbers. It doesn't matter how the groups are separated as the regex pattern

In the password pattern the password's first character must be a letter, contain at least four characters and no more than fifteen characters and no characters other than letters, numbers and the underscore. Naturally the password policy requirement would define what constraints are necessary above the example here.

 

Examples where regex are inappropriate

There are some other use-cases where it may seem appropriate to use regular expressions as a form of validation but in reality there are better methods that can be used instead.

Validating a date for example. The java date object is available for use within groovy in Application Composer and is much simpler to validate whether a valid date has been entered or not. Since it's the leap month of  a leap year let's look at this as an example. Validation of a date should accept 29th February 2016 but 29th February 2015. The date object will correctly validate this but the equivalent regular expression to calculate the same thing is much more tedious.

Likewise zip code validation using regular expressions are simple in verifying the format of the zip code but to verify that the place exists on a map is better served using a post office lookup that will only return physically valid zip codes.

Further Information

 

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.