Before going through this documentation, I am assuming that the user knows the basic ClaySys AppForms Configuration including rules and data sources.
A comprehensive configuration encompasses all the aspect of assembling the Forms, Controls, Rules and Data sources in the smart way. This will improve the performance and readability of the AppForm configuration.
This blog post will help you understand the best practises for ClaySys Appforms are not proposed to form an inflexible methods to follow, they are meant to serve as a guide for creating the application for a specific project.
The AppForm configuration can be divided as follows:
- Deciding the goal
- Finalizing the UI design
- Data Source design (The back end data where you save and process data)
- Deciding the number of form
- Deciding the controls in the form
- Structuring the rules
- Calling the right rule at right time
In AppForms the form is presented to the end user as the HTML, so basically the form is rendered as HTML in the client browser.
If you are not replicating the UI design of another form, keep the number of controls minimal to improve the rendering.
It is very important to decide navigation and number of form even before you start designing, so once you decided the navigation then you can take decision on the number of form you are going to use.
Hidden control
This is a kind of tricky stuff because mostly these hidden controls are used to keep the temporary values. Most of the time the designer will set the visibility of the control as hidden permanently and that control is used as “HIDDEN CONTROL”.
As the project move in agile mode the designer will keep adding the hidden controls just to maintain the temporary value or to control the form logically. When a new designer continue to work on this kind of form, they will be really worried to touch those controls so he will add new controls to it, the end result of this method will be a junk form.
Also if you use a hidden control whenever a value is changed in that control, the AppForms will search for rule for that particular control, this can be avoided.
As mentioned earlier, since this form is rendering as HTML, it will take time to render. But according to the end user there may be only few visible controls and the end user is really worried on the performance in that form .
So how can we avoid this?
There are few methods we can use :
- Managing through variable
- Managing through Session variables
- Reusing the controls
- Keeping only minimal data
“ Even if you wanted to use the hidden controls for managing the form logic then it is better to group the controls using SubForm control, So you can show and hide the controls by just disabling the sub form rather than hiding each controls “
Managing through variables
This is the smartest way to keep the temporary value and traffic the rules. The normal variables can be created from the rules. You have to note that the variables can be accessed only from rules, it cannot be accessed neither from the designer nor from data source.
If it is essential to pass the variable value to the data source then use only one hidden control and pass the variable value to the control. You can use the same hidden control to pass value to the different data source.
Please see the example below:
There are two data sources to save to two different lists, and based on the date of birth they need to save Age to the first data source and based on the Gender they need to save Mr/Miss to the second data source. In this case you have to use the rule to populate the Age from Date of birth and Salutation from Gender. Once you populated you can assign the Age to lblTemp and invoke the save action. Once that is completed you can use the rule to generate the Salutation and assign that to lblTemp and use the same save to the second DB.
Managing through Session variables
Those who have a small glimpse to the programming world they must know the session variable. It can store any data and scope of the session variable is through out the Tenant in the ClaySys, and the life time is till the browser gets closed.
Who need session variables?
Let’s take an example, If I want to maintain a common value called ‘company name’ through out the forms, I can either pass the value between the forms using the controls or use session variable.
Next, if the user want to load form_2 from form_1, but also he want to pass a value from form_1 to form_2, the user can use the session variable to keep that variable.
*Please note the session variables can be used in Data sources.
Reusing the controls
Reusing the control is just what it mean by the title. For example, based on different value you need to perform some operation in the rule. So let try the same by using only two controls, One for the command(txtCommand) and the another one for the value (lblValue). And when you create the rule add the txtCommand as the trigger .
Standard naming practice
In any domain, naming conversion have a great benefit to reduce the effort to read and understand the configuration. It provides a better understanding to the third person who is reading this configuration even after a long time.
The best recommended practices are :
Control
The default name of a control name will be control type + number, leaving this as it is not a recommended process.
The recommenced naming standard is Control Type Short Name + Name +functionality
For example,
Text Box which managed with Name for the Employee info will be, txtEmpInfo.
ComboBox which load the state for Student info will be, cmbStateStudent.
Variable
The variable can be given with a prefix of Var
For Example,
The variable to keep the count will be varCount.
Also you have to note that whenever a variable name is created it should not conflict with the control name or the default rule function name.
Rule
The recommended process for the rule is, it should not conflict with the control name or the default rule function name. Whenever you are giving a sub rule it can be managed in a little more smart way, like
The Child name should be like Parent Rulename_1 and the second level child should be Parent Rule name_2 , like the example below:
Using the right control
While configuring it is advised to use the right control for the right purpose, for example it is not advised to use the Dynamic grid control for the purpose of Search control. The main purpose of dynamic grid is not just to display data but perform the data manipulation operations, also it has composite column feature and lot more, so when you use the dynamic grid instead of search it has to do lot of process before pulling the data to the view .
Sync and Asynchronous operations
Basically the sync and Async operation plays while the time of data Source related command like Execute command and FillData command.
What is Synchronous operation ?
When the user choose the synchronous operation for the execution then it will block the next operation till the synchronous execution is complete, It is advised when you use the execute command as the last action.
OR if there is only one or two execution. Basically synchronous operation is advised to the basic forms.
What is Asynchronous operation ?
Asynchronous operation take the advantage of parallel processing, like the Async execution will not block the next operation.
The user can use two methods to manage this, use the Execute completed and Fill Data completed trigger. Please refer the Execute Complete trigger and Fill Data complete trigger from the ClaySys AppForms documentation.
The second option is set the execution result to a control while configuring the data source and add that control as trigger to a rule, so when the execution is completed the result will set in to the control and the control will trigger its rule.
Rules in the AppForms are the brain when the user wants to control the flow of his execution. So please note the better practice as below:
For example
txtName.value=”anto.Rubin” (good practice)
lblName.Value=anto.Rubin (This will still work but not advised)
According to the architecture of rule engine, when you give a value the rule engine will check is that a control name/Variable/operation, only if that is not a control or variable it will rerun the name. But if we enclose double quotes then it will not check for the same and it will directly return as value .
It is advised to not give same control for different rules, but you can call the required rule using RunRule() function.
There is an option in the designer to check is there any syntax issue in the rules. If you leave as it is, the remaining rule will still work but that error part will be executed as rejected by the rules engine each time.
This is a big no no in the rules. This is like adding the control as trigger and setting value to the same control from the same rule. Also there are lot of recursions where the user use for the purpose of looping, and in that case the user must proof the looping logic with and entering condition. see the example below:
In the above example the varIcount will control the execution of the LoopRule.
