Workflow Basics – Form Validation

So you’ve built a form, and you want to validate the user’s input?  I decided a long time ago that I’m not satisfied with Workflow’s use of the standard window.alert dialog:

Symantec Workflow Simple Validation Popup
The standard javascript window.alert method.

In this article, I’m going to go over the methods I use for Workflow popup boxes, and in particular, validation error messages.  An example of a validation error message box:

Symantec Workflow - Replace the Alert
“You have an appealing coiffure.” -Seven of Nine


There are several ways to accomplish form validation.

Validation – Button Component (“Use Custom Validation”)

Symantec Workflow Form Element Custom Validation
Many form elements contain a section and functionality for custom validation models.

There’s also simple validation, by using path requirements like this:

Symantec Workflow Form Element Output Path Validation
Simple validation is available for most components that have an output variable. Required means a value must exist to continue on the path. Optional means that the variable and its value persist down the path, but that value isn’t required. Ignored means that the variable and the value as it exists on the form will be ignored down that path, and may not exist if it hasn’t been declared ahead of the form.

Some components display their simple validation differently, such as ListSelect components:

Symantec Workflow Form ListSelect Output Path Validation
The ListSelect component requires a right-click to directly access its simple validation rules.

By matter of personal preference, I’m partial to using an external validation model in almost all circumstances for full-form validation.  Here are some tricks to make form validation seamless and friendly.


Set simple validation on all components to “Optional”

By setting all elements to “Optional”, we allow the external validation model to handle all our validations the way we want it to handle it, without the bland, universal window.alert popup telling us what to do.  A quick way to set validation rules for all elements on a page is to configure the rules per output element (like a button).

Symantec Workflow Form Output Element Validation Rules
This image illustrates how to set Required rules on a specific button, for all variable elements on the form.

Declare an Errors Array Variable

Ahead of your form and validation models, go ahead and declare the array you’re going to use to hold any errors that the form may trigger.  A single text array is well-suited for this purpose, and can be declared either with an Initialize Data component or an Add New Data Element component.


Construct an Embedded Rule Model (Validation Model)

Inside this model, we will typically find a number of Text Exists and other input evaluation components.

Symantec Workflow Form Validation Model
A validation model. Using a text array, errors are added as they are found, and the array is then displayed to the user. The first element after Start is used to clear and declare the full errors array, as well as a text error flag which is evaluated at the end of the model to determine whether the datastream returns to the form and displays any errors.

Using Add Items To Collection components, we’ll add a custom error each time an evaluation determines one is needed.

Symantec Workflow Form Validation Error Handling
The error message is tailored to verbally describe the evaluation failure that triggered it.

The final text evaluation reads: “Do any errors exist in the errors array?”  If so, set the text error flag variable value to “true”.  If not, exit via the “Valid: path and leave the error flag = “false”.


Displaying the Errors Array

Now that the errors have been gathered into a text array, how do we display those errors nicely to the user?  We don’t want to have to reserve UI real estate for error elements.  Instead, let’s use a conditional Subdialog window.

2014-11-06_17-10-55

The small square component by the “Error Dialog” Subdialog component is an IncludeHTML component.  The guts of this component:


#ErrorPopup {
visibility: hidden;
}

where the “#ErrorPopup” id belongs to the “Error Dialog” component.  Setting visibility: hidden is different than using Workflow’s visibility model; hiding the component allows us to still functionally use/call the element, while setting the Workflow visibility model to “False” renders that component almost useless while it’s invisible.

So what we have then is a hidden Subdialog button, with the error popup form built inside and the error array neatly assembled on the form.

Symantec Workflow Embedded Dialog
A simple ListItems component can be used to nicely display the errors array.

But now how do we show that, if the ingress button is hidden?  And even if the button wasn’t hidden, would the user then have to press the button to see the errors?  Nope, javascript will assist.

Body onload:


if ([ValidationError])
{ document.getElementById('ErrorPopup').click(); }

where the “[ValidationError]” variable is a text value of either “true” or “false”.  We can’t use a real logical/boolean value, as the text for that renders as “True” or “False”, and the initial capital letter prevents the evaluation’s success.  “ErrorPopup” is the Control Id of the Subdialog component.

So in essence, we have a Subdialog component hidden on the page, just waiting for a call.  When the form loads, a quick evaluation is processed, and that outcome determines whether the hidden Subdialog is secretly click()ed.

The final result:

customformvalidation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s