Skip to main content

AngularJS - Build a custom validation directive for using multiple emails in textarea

AngularJS already supports the built-in validation with text input with type email. Something simple likes the following:
<input name="input" ng-model="email.text" required="" type="email" />
<span class="error" ng-show="myForm.input.$error.email">
        Not valid email!</span>

However, I used a text area and I wanted to enter some email addresses that's saparated by a comma (,). I had a short research and it looked like AngualarJS has not supported this functionality so far. Therefore, I needed to build a custom directive that I could add my own validation functions. My validation was done only on client side, so I used the $validators object.

Note that, there is the $asyncValidators object which handles asynchronous validation, such as making an $http request to the backend.

This is just my implementation on my project. In order to understand that, I supposed you already had experiences with AngularJS and you can catch my point here.

Html code
<textarea rows="3" class="form-control"
 id="dnNoticeInterfaceOtherEmail" name="dnNoticeInterfaceOtherEmail" 
 ng-model='noticeInterface.email.toAddress' ng-maxlength="500" ng-required="true"
 ng-init="dnNoticeInterfaceDialogForm.dnNoticeInterfaceOtherCCEmail.$validate()"
 dn-multiple-email-validator>
</textarea>

<div ng-messages="dnNoticeInterfaceDialogForm.dnNoticeInterfaceOtherEmail.$error" ng-show="dnNoticeInterfaceDialogForm.$submitted" role="alert">
 <div class="alert alert-danger" ng-message="required">
  This field is required.
 </div>
 <div class="alert alert-danger" ng-message="maxlength">
  This field only is allowed up to 500 characters
 </div>
 
 <div class="alert alert-danger" ng-message="dnMultipleEmailValidator">
  This field required a valid email format
 </div>
</div>

Javascript code
//DIRECTIVE FOR NAME MULTIPLE EMAILS
angular.module("dnStandard").directive("dnMultipleEmailValidator", dnMultipleEmailValidatorImpl);
function dnMultipleEmailValidatorImpl() {
 return {
  require: 'ngModel',
  link: dnMultipleEmailValidatorLinkImpl
 };
};

function dnMultipleEmailValidatorLinkImpl(scope, element,  attributes, controller) {
  controller.$validators.dnMultipleEmailValidator = function(modelValue, viewValue) {
   var errorFlag = true;
   if (!controller.$isEmpty(viewValue)) {
   var emailIdsArr = viewValue.split(/,|;/g);
       angular.forEach( emailIdsArr, function( value, key ) {
         if (!dnPattern.EMAIL_PATTERN.test(value.trim())) {
            errorFlag = false;
         }
       });
  }
    return errorFlag;
  };
}

dnPattern.EMAIL_PATTERN =  /^(([^<>()[\]\\.,;:\s@\"]+(\.[^<>()[\]\\.,;:\s@\"]+)*)|(\".+\"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/

References:
[1]. https://docs.angularjs.org/api/ng/input/input%5Bemail%5D
[2]. http://www.treselle.com/blog/angularjs-directives/
[3]. https://docs.angularjs.org/guide/forms

Comments

Popular posts from this blog

DevOps Toolchain Enhancement

 Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today,  it is even treated as a mandatory factor...

Gzip upload on browsers

Today, I faced a problem that I could not upload my archive file with gzip format on Firefox, even it worked on Chrome. I was using macOS. My application had a setting to whitelist accepted files. I’ve already added "application/gzip" to that list. "It’s strange!", I thought. I finally figured out that my uploaded file's type actually was "application/x-gzip" on Firefox. I also asked my colleagues to check their uploaded files on Window and Ubuntu. Hmm… they were totally different! It was "application/x-compressed" on Window, and was "application/x-compressed-tar" on Ubuntu. In fact, gzip is already standardized by IANA. There is a note in RFC-6713 as below: "Some applications have informally used media types such as application/gzip-compressed, application/gzipped, application/x-gunzip, application/x-gzip, application/x-gzip-compressed, and gzip/document to describe data compressed with gzip. The media types defin...

The HelloWorld example of JSF 2.2 with Myfaces

I just did by myself create a very simple app "HelloWorld" of JSF 2.2 with a concrete implementation Myfaces that we can use it later on for our further JSF trying out. I attached the source code link at the end part. Just follow these steps below: 1. Create a Maven project in Eclipse (Kepler) with a simple Java web application archetype "maven-archetype-webapp". Maven should be the best choice for managing the dependencies , so far. JSF is a web framework that is the reason why I chose the mentioned archetype for my example. 2. Import dependencies for JSF implementation - Myfaces (v2.2.10) into file pom.xml . The following code that is easy to find from  http://mvnrepository.com/  with key words "myfaces". <dependency> <groupId>org.apache.myfaces.core</groupId> <artifactId>myfaces-api</artifactId> <version>2.2.10</version> </dependency> <dependency> <groupId>org.apache.myfaces.core<...

Automating deployment and managing apps on OpenShift

Previously, we maintained OpenShift templates for deploying apps in development environments as well as delivering these templates to our customers for their on-prem deployment. Customers who refer to our templates (as well as documentation) have their own configuration management tools to automate the deployment such as ArgoCD and FluxCD. My son's buildings Our developers usually modify templates (YAML) directly on OpenShift for testing and then adjust the corresponding templates stored in the Git repository in Bitbucket. This sometimes causes an issue that delivered templates are incorrect because: - Developers forget to update the templates in Git repositories. - Developers don’t test the templates Therefore, our goal was to integrate a tool into our CI/CD that can automate and manage the configuration of OpenShift apps. The delivered templates should be the ones that are able to run on our OpenShift with the following purposes: - Automate deployment from templated in Git repos...