
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.
✅ PROS:
Easy to implement
Prevents user from submitting incorrect data
Allows using PL/SQL for validation (Regular Expressions and Pattern Matching, custom functions, etc.)
❌ CONS:
Requires full page submit
User can't see the error before page is submitted
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.
✅ PROS:
Easy to implement
Prevents user from submitting incorrect data
Shows a detailed error, including a text and an icon next to the item
No need to define additional validation (like in previous method)
❌ CONS:
Requires full page submit
User can't see the error before page is submitted
Doesn't allow using Regular Expressions and custom code to validate the input
Validation is not very accurate - for example it will allow a string like invalid@email
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
✅ PROS:
Easy to implement
Prevents user from submitting incorrect data
Shows a detailed error, including a text and an icon next to the item
No need to define additional validation (like in previous methods)
Allows validating multiple emails
Validation is as accurate as your Regular Expression - in other words, it could be very accurate
❌ CONS:
Requires full page submit
User can't see the error before page is submitted
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
✅ PROS:
Triggered only when needed
Uses Dynamic Action, no full page submit needed
Allows using fine grained validations using both PL/SQL and Javascript code
❌ CONS:
More steps needed to implement
Requires additional JS library
Requires additional process "Before Page Submit" to trigger the same check in order to prevent user from sending invalid email to the database
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!
@plamen_9 on Twitter
Plamen Mushkov on LinkedIn
Great write-up, thank you Plamen!
LikeLiked by 1 person