- Leverage the existing framework in the market
- Make the form validations dynamic and easy to understand with business/domain experts
- Keep the UI validation form on the client side to avoid round trips and/or degrading the UX expression of users.
- Make sure there is a single source of truth that will be used for UI validation
Let’s assume we have a form like the one below:
Now let’s see how we can address the challenges. To address this [Challenge #1], let’s pick jQuery validation plugin which is very popular. We need now to provide a JSON object to jQuery validator plugin in order to set it up with the related fields.
- Now the Decision Table is the ‘source of truth’ that can be shared across different processes (i.e. UI for form validation and Server for the process input validation. [Challenge #2])
As the result of executing this model you get a JSON object for your UI validation library:
The best practice for UI validation is to ensure the page does not made any unnecessary server calls to validate the users input.
In this scenario, on the page load we run the Decision Table that creates the JSON object for rules and pass the JSON object like any other resources to the web page. Then, the webpage uses the JSON object and configures the validator – in this case jQuery Form Validation plugin, although it can be any other form validation library. So, there would not be any round trip to the server at all. The page has the rules (the created JSON object by Decision Table) on the page load. [Challenge #4].
This approach will:
- Create a single source of truth to be used across different boundaries
- Avoid the extra round trips on user data entry
- Allow validation rules to be modeled and managed outside of your application code as a resource
Last updated January 14th, 2020 at 07:42 am, Published January 31st, 2017 at 07:42 am