Advanced Masked TextboxLast Updated: 02/15/2016 Introduced in Verision: 2.0 |
This tutorial demonstrates how to use Custom Advanced Masked Textbox component on the Form. With this component designer is able to use Regular Expressions for User input Validations. In computing, regular expressions provide a concise and flexible means for identifying strings of text of interest, such as particular characters, words, or patterns of characters. Regular expressions (abbreviated as regex or regexp, with plural forms regexes, regexps, or regexen) are written in a formal language that can be interpreted by a regular expression processor, a program that either serves as a parser generator or examines text and identifies parts that match the provided specification.
Example:
In this example we are going to create a Form with Custom Advanced Masked Textbox components. These components will require Users to input valid Values into Textboxes.
We start in Designer Folder with clicking Create Flow on the Folder Actions Panel.
Then, we Name the Flow and click Create to proceed to the Flow Designer.
In the Flow Designer we add Show Form step from the Favorite Steps category.
Next, we Name our Form and click Create to proceed to the Form Designer.
First, we add Button component from Actions category to our Form.
Next, we add Labels from Data category…
Then, we add Advanced Masked Textbox component from Data category.
We configure Advanced Masked Textbox as following… We define Data Name, set Required Outcome to our Button, and for the Mask Data Value Type we pick Custom.
For User Name we define Custom Mask with following Regular Expression…
We begin by telling the parser to find the beginning of the string (^), followed by any lowercase letter (a-z), number (0-9), an underscore, or a hyphen. Next, {3,16} makes sure that are at least 3 of those characters, but no more than 16. Finally, we want the end of the string ($).
Then, we add Advanced Masked Textbox component for Password. We configure this component in the similar way as previous. For the Custom Mask we use the following pattern…
Matching a password is very similar to matching a username. The only difference is that instead of 3 to 16 letters, numbers, underscores, or hyphens, we want 6 to 18 of them ({6,18}).
Next, we add Advanced Masked Textbox for Hex Value and configure it with following pattern for Custom Mask.
We begin by telling the parser to find the beginning of the string (^). Next, a number sign is optional because it is followed a question mark. The question mark tells the parser that the preceding character — in this case a number sign — is optional, but to be “greedy” and capture it if it’s there. Next, inside the first group (first group of parentheses), we can have two different situations. The first is any lowercase letter between ‘a’ and f or a number six times. The vertical bar tells us that we can also have three lowercase letters between ‘a’ and f or numbers instead. Finally, we want the end of the string ($).
The reason that I put the six character before is that parser will capture a hex value like #ffffff. If I had reversed it so that the three characters came first, the parser would only pick up #fff and not the other three f’s.
For the Slug we are using following Regular Expression…
We begin by telling the parser to find the beginning of the string (^), followed by one or more (the plus sign) letters, numbers, or hyphens. Finally, we want the end of the string ($).
Next, we configure Advanced Masked Textbox for Email Address.
We begin by telling the parser to find the beginning of the string (^). Inside the first group, we match one or more lowercase letters, numbers, underscores, dots, or hyphens. I have escaped the dot because a non-escaped dot means any character. Directly after that, there must be an ‘at’ sign. Next is the domain name which must be: one or more lowercase letters, numbers, underscores, dots, or hyphens. Then another (escaped) dot, with the extension being two to six letters or dots. I have 2 to 6 because of the country specific TLD’s (.ny.us or .co.uk). Finally, we want the end of the string ($).
Then, we configure URL Advanced Masked Textbox with following Regex…
This regex is almost like taking the ending part of the above regex, slapping it between “http://” and some file structure at the end. It sounds a lot simpler than it really is. To start off, we search for the beginning of the line with the caret.
The first capturing group is all option. It allows the URL to begin with “http://”, “https://”, or neither of them. I have a question mark after the s to allow URL’s that have http or https. In order to make this entire group optional, I just added a question mark to the end of it.
Next is the domain name: one or more numbers, letters, dots, or hyphens followed by another dot then two to six letters or dots. The following section is the optional files and directories. Inside the group, we want to match any number of forward slashes, letters, numbers, underscores, spaces, dots, or hyphens. Then we say that this group can be matched as many times as we want. Pretty much this allows multiple directories to be matched along with a file at the end. I have used the star instead of the question mark because the star says zero or more, not zero or one. If a question mark was to be used there, only one file/directory would be able to be matched.
Then a trailing slash is matched, but it can be optional. Finally we end with the end of the line.
For the IP Address we use next pattern…
The first capture group really isn’t a captured group because was placed inside which tells the parser to not capture this group (more on this in the last regex). We also want this non-captured group to be repeated three times — the {3} at the end of the group. This group contains another group, a subgroup, and a literal dot. The parser looks for a match in the subgroup then a dot to move on.
The subgroup is also another non-capture group. It’s just a bunch of character sets (things inside brackets): the string “25” followed by a number between 0 and 5; or the string “2” and a number between 0 and 4 and any number; or an optional zero or one followed by two numbers, with the second being optional.
After we match three of those, it’s onto the next non-capturing group. This one wants: the string “25” followed by a number between 0 and 5; or the string “2” with a number between 0 and 4 and another number at the end; or an optional zero or one followed by two numbers, with the second being optional.
We end this confusing regex with the end of the string.
Finally, we add Advanced Matched Textbox component for HTML Tag validation and configure it in the following manner…
As usually, we begin with the start of the line.
First comes the tag’s name. It must be one or more letters long. This is the first capture group, it comes in handy when we have to grab the closing tag. The next thing are the tag’s attributes. This is any character but a greater than sign (>). Since this is optional, but I want to match more than one character, the star is used. The plus sign makes up the attribute and value, and the star says as many attributes as you want.
Next comes the third non-capture group. Inside, it will contain either a greater than sign, some content, and a closing tag; or some spaces, a forward slash, and a greater than sign. The first option looks for a greater than sign followed by any number of characters, and the closing tag. \1 is used which represents the content that was captured in the first capturing group. In this case it was the tag’s name. Now, if that couldn’t be matched we want to look for a self-closing tag (like an img, br, or hr tag). This needs to have one or more spaces followed by “/>”.
The regex is ended with the end of the line.
This completes our Form design. We can save the Form and close Form Designer. Back in the Flow Designer we connect the outcome from the Form to the End Step. Then, we click Debug Flow link on the top panel of the Flow Designer to test our Flow.
Note that in Decisions version 3.5 and above, you’ll need to click Test Flow to access the Debugger.
Our Form opens in the Debugger. We intentionally fill in the Textboxes with invalid Values and see Validation issues.
Then, we change the inputs to Valid and click Submit.
Our Flow runs to the End Step without any issues…
