+44(0)1908 545 770
YOUR EXPERT RPA PARTNER

Team up with our RPA strategy and tech specialists for maximum automation impact

Find out more
Harness the power of UiPath in your business.
WATCH NOW

Save money and spend more time on priority work.

Book consultation
READY, SET, AUTOMATE

Let's choose, design and deploy a process automation solution for your business.

Find out more
TRANSFORM YOUR BUSINESS

Let's analyse your business to discover opportunities for innovation and automation.

Find out more

Begin your business transformation journey

Book consultation
AUTOMATE EVERY FUNCTION

Automate where it matters most. Scale to solve challenges in every area

Find out more
GIVE EVERY TEAM THE TOOLS FOR SUCCESS

Equip people with user-friendly solutions that save time and make work easier

Find out more

Which business problem
can we solve first?

Book consultation
13 March 2015

Validation input with K2 SmartForms – Part 3: Complex Client Side Validation

This is the 3rd part of a short series of articles on validation with K2 SmartForms. In the previous article, Part 2, we looked at simple client side validation using the built in validation functionality provided by K2 SmartForms. This article will build on the base we established there and take it a little further to address more complex requirements. To recap, lets have a quick look at our example form again.

validation input with k2 smartforms

Image 1 – Complex Client Side Validation – Example form

K2 Automated Testing Software

BenchQA allows full test automation of K2, including fully automated K2 SmartForms and K2 Workflow testing. It promotes test driven development for K2 and ensures continued quality assurance for K2 solutions. Easily apply changes to test cases to accommodate changes to K2 apps and ensure all apps are regression tested to avoid defects and assure continuous quality.

 

Free K2 Five Upgrade Review

We will specifically look at the following requirements:

1. The Expiry Date needs to be in the future.
2. The Expiry Date needs to be after the Issue Date.
3. The Description is required only if the document type is ‘Official’.

Example one and two are representative of situations where we will need to implement validation based on more than one field. Example three is representative of a situation where the value of one field determines whether another field is required or not. Both these scenarios are cases where the default validation mechanism provided by K2 falls a little short, but fortunately we can dig into our bag of tricks to make it work.

The Expiry Date needs to be in the future.

In example one it seems as if only one field is involved in the validation, but because we need today’s date there is actually two fields involved. Lets start by addding a calender control containing today’s date to the form. We do this by dragging a calender control onto the form and then set the default value in the properties panel to ‘Today (Current Date)’.

Image 2 - Complex Client Side Validation - A calender control containing today's date

Image 2 – Complex Client Side Validation – A calender control containing today’s date

We do not want the user to see this date, so we will hide the control by setting its visibility to false.

Image 3 - Complex Client Side Validation - Setting the visibility to false

Image 3 – Complex Client Side Validation – Setting the visibility to false

The next step is to insert a dummy textbox control which we will be using to validate against. The naming of this control is extremely important, as we will be using it to inform the user of the requirement. We will name the control ‘Expiry Date needs to be in the Future’. Additionally we will also set the visibility of this control to false, because we do not want the user to see it as it is only for validation purposes.

Image 4 - Complex Client Side Validation - Hidden text box used for validation

Image 4 – Complex Client Side Validation – Hidden text box used for validation

Next we will bind this dummy control to an expression, which we will use to trigger the validation. What we will be doing in the expression is to assign an empty string when the expiry date is in the past, and any dummy value when the date is in the future and valid.

Image 5 - Complex Client Side Validation - Expression used to force a validation error

Image 5 – Complex Client Side Validation – Expression used to force a validation error

The next step is to add a validation rule like we did previously. We add the rule when the create button is clicked.

Image 6 - Complex Client Side Validation - Adding a validation rule

Image 6 – Complex Client Side Validation – Adding a validation rule

Next we need to configure our validation rule. We will mark our dummy expression text box as required, and then uncheck the ‘Do not validate hidden controls’ checkbox to indicate that hidden controls should also be validated. Additionally we will check the box to show validation messages in a popup.

Image 7 - Complex Client Side Validation - Configuring the validation rule

Image 7 – Complex Client Side Validation – Configuring the validation rule

Well, lets see what happens when we select a past date and try to save. We get a warning popup saying ‘Expiry Date needs to be in the Future a value is required’.

Image 8 - Complex Client Side Validation - Error being displayed

Image 8 – Complex Client Side Validation – Error being displayed

One of the things that this solution lacks is a visual indicator on the screen, like a red border around the expiry date, to indicate when it is in error. We can optionally solve that by inserting some jquery into the page, but for now this will do. The  ‘Expiry Date needs to be in the Future: a value is required’.  text is also not ideal, and we will see how to change that in the next section.

The Expiry Date needs to be after the Issue Date.

For this requirement we will take it one step further and include a control validated based on a regular expression to improve the validation message. First lets add a dummy textbox, hide it, and name it ‘Expiry Date’. Now bind the textbox to an expression which will contain the value 1 for true if our expiry date is in fact in the future, and 0 for false if our expiry date is in the past.

Image 9 - Complex Client Side Validation - Configuring the expression

Image 9 – Complex Client Side Validation – Configuring the expression

Next we will setup regular expression based validation on the textbox. Go to the validation section in the properties window, select Regular Expression and add a new expresion containing the following: ^[1]{1}$. This basically says that the textbox needs to contain a 1. For the message enter the following: ‘needs to be after the Issue Date’.

Image 10 - Complex Client Side Validation - Adding the regular expression

Image 10 – Complex Client Side Validation – Adding the regular expression

And lastly we need to edit our validation rule added previously to also validate this new textbox. Great, and now when we press save with an issue date after an expiry date we get prompted with the following message: ‘Expiry Date needs to be after the Issue Date’

Image 11 - Complex Client Side Validation - The error being generated

Image 11 – Complex Client Side Validation – The error being generated

The Description is required if the document type is ‘Official’.

For this requirement we will once again make use of a hidden textbox control, but the process is a little simpler than the previous two examples. First add the hidden textbox, and name it Description. Now bind this textbox to an expression, which will insert an empty string into the textbox when the document type is ‘Official’ and any dummy string of non-zero length when the document type has not been selected as ‘Official’.

Image 12 - Complex Client Side Validation - Configuring the expression

Image 12 – Complex Client Side Validation – Configuring the expression

Finally go to the validaiton rule we have previously set up and mark this textbox to be validated as well. So what now happens is that if ‘Official’ is selected as the document type the dummy textbox contains an Empty String, and when we save the following validation message is displayed: ‘Description: a value is required’.

Image 13 - Complex Client Side Validation - The error being generated

Image 13 – Complex Client Side Validation – The error being generated

Well, that is it for Part 3 of the series on validation. Hope to see you next time for Part 4 where we will be looking at how we can add some server side validation to our application.

Need further technical advice or support?