APEX validations: Email address

In this (and the next) blog posts I will demonstrate different techniques for validating user input in Oracle APEX. I bet you needed to validate an item – for example if the user has entered a valid e-mail address, a valid number, a valid name or phone number, a valid license plate, personal id number – you name it. Read how you can achieve that using the APEX built-in functionalities, using third party Javascript libraries or simply by using CSS and HTML attributes.

After I demonstrate all the options you can check the chart with pros and cons and decide for yourself which type of validation fits your application best. What I find best is combining several of them to achieve the best in terms of speed, functionality and user experience.

So the possible options to validate an e-mail covered in this post are:

🔸 Using Validation on page submit
🔸 Defining the page item as Text Field type and e-mail subtype
🔸 Using the pattern HTML attribute for your input
🔸 Using a Dynamic Action
🔸 Using the validator.js JavaScript library

🎁 As a bonus I will show you how to add some fancy animation when user enters invalid e-mail.

See the E-mail validations demo in action here: https://apex.oracle.com/pls/apex/r/gamma_dev/demo/email-validation

Method 1 – Validation on Page Submit

The most popular and widely used method – it’s the good old item validation. The validation displays some error message in case the user input in a Text Field is not a valid email address. It is triggered on page submit. Here you could use regular expressions or any other PL/SQL functions to check the provided string.

select 1
from dual
where not regexp_like (nvl(:P21_EMAIL_SUBMIT,'n/a'), '^[A-Za-z]+[A-Za-z0-9.]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$')

Method 2 – Using the Text Field “E-Mail” subtype

Oracle has made it easy for us to validate some of the most popular types of strings that users need. You can select between number, email, phone number, search, URL and so on. Selecting the E-Mail subtype would trigger an auto validation on beach submit. It will also tell you the exact error you have in your text such as missed @. The Subtype can be found under Settings for the items of type Text Field.

Method 3 – HTML pattern attribute

A method that most people probably haven’t tried. It allows validation of all kinds of inputs using a Regular Expression and the special pattern attribute. In the case of validating E-mails there is another attribute – multiple, which allows validating multiple emails which are coma separated.

 <input type="email" pattern="[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}$">

The user input will be checked for the above pattern. It will immediately alert the user if the string is not a valid email and will not allow page submit.

 <input type="email" multiple>

The multiple attribute will allow validation of multiple email addresses, separated by a comma. For example email1@multiple.eml,email2@multiple.eml

BONUS – Make Method 2 & 3 user friendly using just one CSS property

For the previous two methods we said that you need to submit your page before you can see the error. Yes and No. Yes, you need to submit before you can see the detailed errors.

And No, with a pinch of CSS magic you can alert the users as they type that their string is invalid email. To do that, assign a custom class to each Text Field in Advanced > CSS Classes. I have named mine email_validate. Very important here is the input:invalid CSS style. It basically allows us to assigns different CSS style as soon as the input has incorrect data.

input.email_validate:invalid {
      animation: shake 0.2s ease-in-out 0s 3;
      box-shadow: 0 0 0.3em 0.05px red;
}

@keyframes shake {
      0% { margin-left: 0rem; }
      25% { margin-left: 0.5rem; }
      75% { margin-left: -0.5rem; }
      100% { margin-left: 0rem; }
}

Method 4 & 5 – Dynamic Action + Javascript

I have decided to combine these two methods in one. You could have a Dynamic Action that does the Text Field validation using Server Side PL/SQL (Regular Expression Pattern Matching, Substringing, Custom functions, etc.) or using Client Side Javascript (validator.js). In this case, we will have a Dynamic Action, triggered on “Lose Focus” event of the Text Field. This will allow for the validation to be triggered only when the user has stopped typing and is switching to other element on the page.

To include the Validator Javascript library, you can use the following URL (added to the JavaScript File URLs of your APEX page):

https://cdnjs.cloudflare.com/ajax/libs/validator/13.7.0/validator.min.js

if (validator.isEmail(apex.item("P21_EMAIL_DA").getValue())) {
   // Displays a page-level success message ‘Valid email!’.
   apex.message.showPageSuccess("Yes, it is a valid email!");
} else {
   // Now show new errors
   apex.message.showErrors([
      {
         type:       "error",
         location:   "page",
         message:    "Not a valid email address!",
         unsafe:     false
      }
   ]);
};

What did I chose?

As you can see, there are PROS and CONS in each of the above methods. However, I think that several are the most important points that you have to handle, everything else is a mater of choice:

• Validation should be as good as possible. That’s why I would use either custom PL/SQL (or HTML pattern Regular Expression) … or external library for that.
• Limit the calls to the database and do as much as possible on the Client Side – so here my favourite is the pattern HTML attribute and the Dynamic Actions
• Make it user friendly, that’s why I will probably go with the shake CSS effect to notify the users as they type (or at least as they leave the input)
• Do not allow invalid strings to get inserted into the database – always make sure your method of choice is secured against that.

Check the demo again here:
https://apex.oracle.com/pls/apex/r/gamma_dev/demo/email-validation

Liked that post? Follow me on Twitter and LinkedIn!