Screen capture of validator returning an error to user in AEM

BlackBerry Form Validator

team

Individual project, while working for BlackBerry

tools

Eclipse, JavaScript, XML, RegEx, Git

my role

Web Developer

brief

After seeking additional work and challenge during my work term, I was assigned this task by one of the Web Applications Developers on the Digital Marketing team. I needed to restrict the acceptable input characters for the name field of multiple components on BlackBerry's authoring site. June to August 2018.

research

When I was given this job, there was no clear or required deadline, but it was clear that it was an important issue to address. At that time, if someone included a special character in the name of a form component, the form's name would be unreadable to the back-end software. This room for error posed a major issue to the Marketing department, who uses these forms for a variety of purposes including lead generation.

Since this was my first time writing a validator and I had only basic JavaScript experience prior, I found some documents and tutorials online to refresh myself. I also read through documentation on Adobe Experience Manager (AEM), the content management software that was used. I also taught myself about regular expressions (RegEx) at the suggestion of another developer who thought it may be useful.

A screen capture of Screencapture of AEM's documentation on TouchUI dialog values, specifically on writing JavaScript validation code
A screen capture of Screencapture of AEM's documentation on TouchUI dialog values, specifically on writing JavaScript validation code. July 2018.

coding

Once I had my own local host set up, I would work on writing code for the form validator whenever I had spare time around projects of higher priority. To begin with, I wrote smaller functions to test different ideas and to practice the various RegEx expressions.

After a few iterations, I had written a JavaScript function that worked as intended and provided an error message in plain language to indicate the issue and help the user recover quickly. After testing the function and ensuring it wouldn't negatively affect unrelated components, I got permission from the lead developer to push the code to the website's master branch and request that it go to production.

					
"use strict";

use(function () {
	//test function to determine RegExp and relevant properties
	//final goal: restrict the name field for form inputs to only allow letters, numbers, and dashes(-)

	var properties = granite.resource.properties,
	name = properties.name,
	regex = new RegExp("^[a-zA-Z0-9-_]*$"),
	noSpecialChar = regex.test(name);
	specialCharPresent = false;

	if(noSpecialChar == false){
		specialCharPresent = true;
	};

	return {
		name: name,
		noSpecialChar: noSpecialChar,
		specialCharPresent: specialCharPresent
	};
});
					
				

A test function used to determine RegEx and relevant properties. July 2018.

implementation

Once my JavaScript function was pushed to production, it was found that the authoring website could not create forms correctly. As much as my very kind team assured me that it was likely not my code and probably something else, it ended up that it was definitely my code at the root of the issue. They reverted my push, and I was back to working on it again to figure out what was wrong.

After more testing on my own and a pair programming session with one of the Web Applications developers, we found the issue: a line of code I had referred to from AEM's documentation conflicted with other plugins being used on the website. I was able to make the necessary edits to address the major crashing problem, while also taking the opportunity to clean up my code and add comments to allow the function to be edited easily in the future once my co-op term had ended.

					
/*
 Purpose: Restrict the name field for form inputs to only allow letters, numbers, dashes (-), and underscores (_)
 Based on AEM documentation for TouchUI Validation (https://helpx.adobe.com/experience-manager/using/creating-touchui-validate.html)
 Used for the following form components: "consent", "hidden", "options", "text"
*/

(function (document, $, ns) {
    "use strict";

    $(document).on("click", ".cq-dialog-submit", function (e) {
        e.stopPropagation();

        var $form = $(this).closest("form.foundation-form"),
        name = $form.find("[name='./name']").val(),
        campaign = $form.find("[name='./campaign']").val(),
        message, clazz = "coral-Button ",
        patterns = {regex: /^[a-zA-Z0-9-_]*$/};

        /* To verify that the component will only work for the desired components,
        determine the "action" path of the form and confirm the relevant path */
        var formActionPath = ($form[0]).action,
        consentActionPath = formActionPath.search("/consent"),
        hiddenActionPath = formActionPath.search("/hidden"),
        optionsActionPath = formActionPath.search("/options"),
        textActionPath = formActionPath.search("/text");

        /* If-statement uses regex to confirm that only desired characters are used, and checks the component's action path */
        if((!patterns.regex.test(name)) && ((consentActionPath != -1) || (hiddenActionPath != -1) || (optionsActionPath != -1) || (textActionPath != -1))){
        	e.preventDefault();

        	ns.author.ui.helpers.prompt({
        		title: Granite.I18n.get("Invalid Input"),
                message: "Please enter a name that only uses alphanumeric characters, dashes, or underscores. (A-Z, 0-9, \"-\", or \"_\")",
                type: "ERROR",
                actions: [{
                    id: "CANCEL",
                    text: "CANCEL"
                }],
                callback: function (actionId) {
                	if (actionId === "CANCEL") {
                	}
                }
        	});
        }
    });
})(document, Granite.$, Granite);
					
				

The final JavaScript code used in the form validator. August 2018.

reflections

After chipping away at this project, before the end of my internship I was able to provide and implement code for BlackBerry's authoring site. While it wasn't a very complex job, it pushed me out of my comfort zone and showed that I'm willing to work on the fly. While it didn't work flawlessly when it was first pushed, the problems I faced emphasized that iteration needs to happen in one's own work, as code will rarely work perfectly the first time around.

Also, I'm aware that I only got this job assigned to me because I asked for it. Because I approached the developers on my team and made it clear that I wanted to do more code-related work than what I was given day-to-day, I got the opportunity to practice, learn new skills, and grow as a developer.

A screen capture of the validator being used on the AEM authoring site
A screen capture of the validator being used on the AEM authoring site. August 2018.