Perform data validation in E-Forms.
Keep the forms as simple as possible. Adding too much extra functionality into an E-Form can potentially cause performance issues.
Re-use code and configurations that have been successfully implemented in the past.
Add comments to your E-Form code to make changes easier for the system administrator if changes need to be made in the future. In the case where this form becomes part of a support issue, comments in the scripts will help in troubleshooting the issue to see whether the issue is OnBase related or if it is caused by the scripts.
Document what the form is supposed to do and how it should be maintained. This is in addition to adding comments to the pertinent sections of the E-Form code.
You can use a text editor, like Notepad®, to edit and save the revised file as plain text if you are knowledgeable in HTML. HTML editors, like Microsoft Expression Web, are also useful to catch common mistakes and ensure the creation of standards compliant HTML.
Validate any HTML created by using a validation service. The Markup Validation Service from W3C is a useful tool. The service can be found at https://validator.w3.org/
Some HTML editors store extra spaces as which can cause the maximum length of the Keyword Value to be exceeded or produce unexpected search results. It is best practice to not append extra spaces to drop-down Keyword Value select lists. Check the HTML code to confirm that spaces are stored in a way that is compatible with the system database.
It is a best practice to thoroughly test all E-Forms in the main browsers the user base anticipates using. Each implementation will have unique circumstances, so choices for scripting languages and functions used should be based on those circumstances.
When importing the HTML E-Form template into the system, it is considered a best practice to include the name of the Document Type that will use the form in the Description keyword value.
Limit the number of fields on an E-Form. E-Forms are a very powerful tool which makes it easy to expand the amount of information stored on the form. The more fields on the form, the longer it takes to load. Note that hidden fields still take time to load despite the fact that they do not display on the form.
If you do not need to store non-keyword and scripting data on an E-Form, it is recommended that you use Virtual E-Forms. Virtual E-Forms do not take up as much a space on a disk group since they store only information that is saved in the database, such as keyword values and system values.
It is recommended to use Document Type revisions when making form template changes.
Do not build business logic into E-Forms if possible.
When developing for the Web Client, load referenced files (scripts, css, xml, etc.) from an external share. Create a separate virtual directory on the Web Server that is separate and distinct from the OnBase installation. This means that the files are untouched by the installer when OnBase is upgraded.
Never edit the E-Form template directly in its disk group location. If you need to edit your SYS – HTML Form, edit your template (not from the disk group) and re-import the form via the OnBase Client. Then reassign the form to the Document Type in the Configuration module. When you edit the form from the disk group, the Item Size for the file will not be updated in the database and when you attempt to retrieve that template, it is possible OnBase will think that the file has been corrupted and it will not display.