Main Concepts for Dynamic Forms Modeling

In the blog Dynamic Forms Architecture and Design, we saw how rules driven dynamic forms can be architected with a model/view pattern, where the model is defined in a no-code rules development environment and the view can be implemented with any front-end framework. In this blog, we will dive into the main concepts to create a model. We will be using Corticon.js as the no-code development tool for the model.

The main benefit of using Corticon.js is that the business specialist can create and maintain the model. When the model is implemented, Corticon.js can produce a decision service that is directly usable by the view with a simple JavaScript call. We commonly call the model the “Decision Service” component as effectively the model is implementing the business rules and thus making decisions on the flow of questions, as well as which UI to render and when.

Main Concepts

As a modeler, your main responsibilities are to specify:

1. The flow of questions the user will go through (all the possible paths the questionnaire can take). The paths can be viewed as a decision tree, where each branch has its set of questions (of course there is a provision for reusing a set of steps that are common to multiple paths). This requires a deep understanding of the business problem at hand. As a modeler, you will need to work with stage numbers to implement the flow of questions (more on this topic below). The benefit here is that the model insulates the front-end developer of all flow decisions—in other words, the UI developer does not need to understand the specific problem domain or use case. This greatly simplifies the development of the UI, whether as a Web front-end or a mobile application.

2. For each UI step:

• You will model what UI controls to render for the questions to ask. For example, render two text fields for asking the user to enter first and last name. It's important to note that you will model the type of data to be entered—for example, a date—but you are not responsible for specifying how that question is actually displayed in the UI. This is very beneficial, as you can focus on what data you need to ask along the flow of questions without having to worry about how these questions are rendered, asked and responded to.
• You can also implement some computation before executing the next step—for example, computing the total expense amount and branching to additional questions when the amount is greater than a set limit. Corticon.js offers great facilities to achieve these without having to actually write code. For example, in a multi-national travel expense list, one can compute the sum of expense claims for all Hotels in the USA by simply filtering the collection of expenses by currency and expense type and applying the sum operator. Here is an example:

   

3. Where to store the accumulated data entered by the user or data computed at various steps. This will serve two purposes:

• You will need to access some of that data to decide which branch of the flow the questionnaire will go to next. For example, you may ask for gender and branch to a different flow of questions depending on the answer. The model will include a definition of the field gender and you will be able to express different actions based on the value of the gender field.
• At the end of the complex form, all the entered data will typically be sent to other services for further processing, and in most scenarios, that data will be saved to a database. As a modeler, you will need to agree with the front-end developer on the names used for these data fields. The Corticon studio modeling tool provides facilities to publish a documentation of these names.

Incidentally, the fact that the model specifies the data fields for storing answers is a key property to ensure the view remains generic and can be reused across different forms; in other words, the view does not need to know and understand the data for each question, it just needs to use the name specified by the model to store the answer. This greatly simplifies the front-end form development.

Understanding Stage Numbers

What are Stage Numbers?

The stage is a number that uniquely identifies what needs to happen at a specific step of the questionnaire. For example, at stage 2 ask for first name and last name, then at stage 3 ask for gender.

As a modeler and creator of the decision service you decide what stage numbers to assign to the various steps used in the overall questionnaire.

The set of stages the user goes through constitutes a flow. In typical dynamic forms, questionnaires need to go through various flows because the set of questions to ask varies based on answers to previous questions and based on external data (such as user profile data or time of day). For example, the questionnaire can go through stage 1, 2, 3, 4 and 10 if the user answers yes to the first question and through stage 1, 5, 6, 7, 8, 9 and 10 if the user answers no to the first question.

The flow can also be determined by the answers to various questions in the flow. Corticon can scale without issues for the most complex flows independently of the number of conditions to branch with.

We have seen customers implement complex dynamic forms with hundreds of different flows.

Working within Corticon.js Studio

Now that we have seen what the main concepts are, we will take a look at how these concepts are applied within the Corticon studio modeling tool.

Note: the following section assumes you are already trained on Corticon.js studio. If you are not, you may want to check out this free online introductory tutorial. 

What is the Dynamic Form Model in Corticon.js?

The model is composed of a series of Corticon rulesheets and at least one ruleflow including all the rulesheets.

The ruleflow will be used to generate the JavaScript decision service that you will hand over to the front-end developer.

What are the Main Items of a Rulesheet?

You specify these main items:

1. You declare the stage number this rulesheet implements. You use a pre-condition filter. For example, for stage 4, you would express the filter as UI.currentStageNumber = 4
   And you right click on the filter and set the pre-condition filter option.

    

   
   
   

2. You create one or more containers to host the UI controls. Typically, these are the panels that will contain the questions.
3. You add to the container one or more UI controls (a UI control per question to ask). There are various types of controls available. For example, you can create a text input, a numeric input, a single choice (dropdown list), multiple choices (checkboxes), read-only text or a Date and Time UI control. For a full list, see the UIControlType enumeration in Corticon.js vocabulary custom data types.
4. You set the next step to execute in the flow of questions using the next stage attribute. This can be expressed as a conditional expression when you need to branch to different flows. For example, when the user entered yes on the first screen, the next stage is 300 and when the user entered no, the next stage is 400 as illustrated below:

Main Items in Ruleflows

This is the simplest task, as you just need to drag all your rulesheets into the ruleflow canvas. In general, you do not need to connect rulesheets with each other as the order of execution does not matter. This is because the ruleflow will be executed for a specific stage; that is, the view will call the ruleflow (the decision service) specifying the current stage number to execute and as all rulesheets filter on stage number, only the ones that match the filter will execute.

However, there are times when you will need to specify the order of execution. This is will be the case when you implement a stage in multiple rulesheets.

For example, here we can see how step five is implemented in three rulesheets with an explicit execution order.

Conclusion

Corticon is a very versatile product; as such, there are multiple ways to approach and solve problems with it. We have developed one approach, a set of patterns and multiple samples. We have published them on the Corticon public GitHub repo here.

These should help you get started very quickly with complex rules based dynamic forms. Feel free to use the solution as is and adapt it to your own needs as you see fit.

Hopefully, this blog has provided you with enough context to understand the samples on the GitHub, but if not, do not hesitate to reach out.

To get started:

• Invoke client.html (available here).
  
• Go through each sample to get a feel for what is available.
  
• To understand what UI Controls can be used on the form, run the canonical sample. Each step in this sample shows how to use a specific UI control (You can see the name of the corresponding rulesheet file in the title of the container when you want to dig into how the step is implemented in Corticon.js.). 
  
• Reuse the corresponding step rulesheet as an example to implement what you need in your own project.
  

Additional Resources

• Find out more about Corticon.js here. 
  
• You can check out these blogs for Corticon news and features as well as Serverless industry trends.
  
• You can enroll in free training for Corticon.js here.
  

Try Corticon.js