FormView technology
Summary
Designed from the ground up for interoperability and standards,
FormView is a web application that runs on the rock solid Java Enteprise foundation.
It relies on Ajax and JSON for interactions between browser and server,
providing rich and robust communications between them.
The application creates multiple page forms backed by a relational SQL table. The data in each form's fields is harnessed and made available to a server-side Javascript sandbox, where easy to write scripts use and manipulate the data and perform a variety of functions, without requiring Java coding.
A comprehensive script library makes it easy to interact with multiple databases, AD and naming directories, and dynamically populating forms. The library functions also provide the foundation for consuming and creating web services with just a few lines of script.
Combining a WYSIWYG form editor with the easy to use Javascript on the browser and the server and automatic database table maintenance enables a form developer tremendous ability without requiring a large team of HTML, Java and database experts.
In intranets, user profiles are automatically looked up in Active Directory or database tables. Profiles allow verification of other user's identities and provide common attributes such as email addresses and employee ids.
The application creates multiple page forms backed by a relational SQL table. The data in each form's fields is harnessed and made available to a server-side Javascript sandbox, where easy to write scripts use and manipulate the data and perform a variety of functions, without requiring Java coding.
A comprehensive script library makes it easy to interact with multiple databases, AD and naming directories, and dynamically populating forms. The library functions also provide the foundation for consuming and creating web services with just a few lines of script.
Combining a WYSIWYG form editor with the easy to use Javascript on the browser and the server and automatic database table maintenance enables a form developer tremendous ability without requiring a large team of HTML, Java and database experts.
In intranets, user profiles are automatically looked up in Active Directory or database tables. Profiles allow verification of other user's identities and provide common attributes such as email addresses and employee ids.
Technical Architecture
The FormView web application is distributable and designed for multiple instance deployment.
All data used and created by the application is stored in a database. Multiple instances share the database for synchronization.
Nothing is written to the server file system by the application except for temporary upload files while being processed.
Configuration properties are stored in the application's web.xml file or in a read-only, shareable [properties file](#propertiesfile).
Forms are defined using a browser application and are stored in the server's database. These records are cached for a short time, minimizing synchronization lag between instances to the [caching interval](#cachems), whose default value is 15 seconds.
Form designers are provided a scripting language for working with form data dynamically. Scripts can run on both the browser and the server. Typically, browser scripts interact with form elements on the screen as they change, while server scripts deal with the data anywhere in the form and use a library of built-in functions to interact with databases, ldap/AD lookups and REST web services. The Javascript language is used for both browser and server scripts. In the browser, scripts run as native Javascript; in the server, scripts run under the GraalVM Javascript engine.
At runtime, when forms are served, the form definition in JSON is sent to the browser to be turned into HTML. Data submitted by the form is sent to the server in JSON as well. Thus, the entire data flow architecture is ajax/json, rather than the traditional submitted html forms. This results in very efficient usage of server resources.
Each form's data is stored in its own table, one record per form. When a page in the form is submitted, the fields on that page are updated and the rest of the record is left intact. This allows creating applications where more than one user can simultaneously collect and revise data on different pages of a form, and can even simultaneously modify the data on the same page using appropriate functions.
Form access uses sessions with CSRF tokens. Other security techniques used are server and browser data validation, HTML escaping, and prepared SQL statements. The browser and its scripts can only modify data in the current page, while server scripts can deal with data needed in other fields.
An encrypted Wallet is available to store valuable information such as API keys for external web services.
All data used and created by the application is stored in a database. Multiple instances share the database for synchronization.
Nothing is written to the server file system by the application except for temporary upload files while being processed.
Configuration properties are stored in the application's web.xml file or in a read-only, shareable [properties file](#propertiesfile).
Forms are defined using a browser application and are stored in the server's database. These records are cached for a short time, minimizing synchronization lag between instances to the [caching interval](#cachems), whose default value is 15 seconds.
Form designers are provided a scripting language for working with form data dynamically. Scripts can run on both the browser and the server. Typically, browser scripts interact with form elements on the screen as they change, while server scripts deal with the data anywhere in the form and use a library of built-in functions to interact with databases, ldap/AD lookups and REST web services. The Javascript language is used for both browser and server scripts. In the browser, scripts run as native Javascript; in the server, scripts run under the GraalVM Javascript engine.
At runtime, when forms are served, the form definition in JSON is sent to the browser to be turned into HTML. Data submitted by the form is sent to the server in JSON as well. Thus, the entire data flow architecture is ajax/json, rather than the traditional submitted html forms. This results in very efficient usage of server resources.
Each form's data is stored in its own table, one record per form. When a page in the form is submitted, the fields on that page are updated and the rest of the record is left intact. This allows creating applications where more than one user can simultaneously collect and revise data on different pages of a form, and can even simultaneously modify the data on the same page using appropriate functions.
Form access uses sessions with CSRF tokens. Other security techniques used are server and browser data validation, HTML escaping, and prepared SQL statements. The browser and its scripts can only modify data in the current page, while server scripts can deal with data needed in other fields.
An encrypted Wallet is available to store valuable information such as API keys for external web services.
Securing data
Forms are, by default, protected
by requiring application server authentication,
as chosen in the Security page.
HTTPS, by default, is required throughout the application.
Every form submission starts a session, with a unique CSRF token that is checked on every data submission from the form.
Forms are constructed using standard HTML elements. However, forms are not submitted using the <form> tag. Instead, when the form buttons are pressed, Javascript functions collect all page data, send it to the server as an AJAX request, and receive data and markup for the next page, which is rendered as HTML elements after suitable sanitization for script injections.
The current values of form fields on the current page and previously seen pages are available in the browser for browser Scripts, while the current values of all fields on all pages are available to server Scripts.
The server takes several measures to prevent form tampering: - incoming fields that are not on the current page are discarded - all fields are re-validated, just like they were in the browser, for suitable types, value ranges, required, etc. - when server Scripts use the Hide function to make fields invisible or read-only, incoming field values are rejected by the server, preventing tampering, and are discarded before saving the form. However, the Hide function can override these safeguards as necessary.
After validation and executing server side Scripts, the form is saved using prepared SQL statements that modify only the fields on the current page and fields modified by the Scripts.
Altogether, these practices allow forms to be accessed simultaneously by different users safely.. For example, one page can be made accessible for normal access to a reviewer while the author only has access in a View Only mode.
Scripts provide additional fine grain control so that certain fields can be rendered in a read only mode to one class of user and in a fully accessible mode to another user.
Gathered data is presented to users in reports, secured with appropriate access rights; individual reports can use additional restrictions, and individual forms can add restrictions on report access as well.
Every form submission starts a session, with a unique CSRF token that is checked on every data submission from the form.
Forms are constructed using standard HTML elements. However, forms are not submitted using the <form> tag. Instead, when the form buttons are pressed, Javascript functions collect all page data, send it to the server as an AJAX request, and receive data and markup for the next page, which is rendered as HTML elements after suitable sanitization for script injections.
The current values of form fields on the current page and previously seen pages are available in the browser for browser Scripts, while the current values of all fields on all pages are available to server Scripts.
The server takes several measures to prevent form tampering: - incoming fields that are not on the current page are discarded - all fields are re-validated, just like they were in the browser, for suitable types, value ranges, required, etc. - when server Scripts use the Hide function to make fields invisible or read-only, incoming field values are rejected by the server, preventing tampering, and are discarded before saving the form. However, the Hide function can override these safeguards as necessary.
After validation and executing server side Scripts, the form is saved using prepared SQL statements that modify only the fields on the current page and fields modified by the Scripts.
Altogether, these practices allow forms to be accessed simultaneously by different users safely.. For example, one page can be made accessible for normal access to a reviewer while the author only has access in a View Only mode.
Scripts provide additional fine grain control so that certain fields can be rendered in a read only mode to one class of user and in a fully accessible mode to another user.
Gathered data is presented to users in reports, secured with appropriate access rights; individual reports can use additional restrictions, and individual forms can add restrictions on report access as well.
Requirements
The FormView application is a Servlet 3.1
compliant Java EE web application. It supports Java VM versions 11, 17 and 21.
The application has been tested on the latest available versions of JVM 11, 17 and 21 from Oracle: JDK 21.0.5, JDK 17.0.12, JDK 11.0.24.
FormView requires a Java EE or Jakarta EE application server, such as Tomcat 8 through 11, WebLogic Server 12c and 14c, JBoss EAP 7 and 8, WildFly. Other application servers can be certified upon request. It runs on hardware and operating systems supported by the application server and Java VM.
FormView stores its data in a relational database. The following are supported: - Oracle 12 and higher - MySQL 5.7, 8.0, 8.4, 9 - Others (DB2, Postgresql, MSSQL) can be certified upon request
FormView requires a web browser with EcmaScript11 capability, which is all web browsers released after 2020. It does not support Internet Explorer or Edge in Internet Explorer mode.
The application has been tested on the latest available versions of JVM 11, 17 and 21 from Oracle: JDK 21.0.5, JDK 17.0.12, JDK 11.0.24.
FormView requires a Java EE or Jakarta EE application server, such as Tomcat 8 through 11, WebLogic Server 12c and 14c, JBoss EAP 7 and 8, WildFly. Other application servers can be certified upon request. It runs on hardware and operating systems supported by the application server and Java VM.
FormView stores its data in a relational database. The following are supported: - Oracle 12 and higher - MySQL 5.7, 8.0, 8.4, 9 - Others (DB2, Postgresql, MSSQL) can be certified upon request
FormView requires a web browser with EcmaScript11 capability, which is all web browsers released after 2020. It does not support Internet Explorer or Edge in Internet Explorer mode.
Performance
FormView has been stress tested with 100 simultaneous requests
at constant speed of over 2,000 requests per second
on a Mac M1 with Tomcat.
FormView uses the GraalVM Javascript engine for server side scripts, and includes the necessary libraries. The Graal native compilation feature is not used because it only provides a 5% increase in overall performance and requires specific builds for specific versions of the Graal VMs. Contact Cogix if interested.
FormView uses the GraalVM Javascript engine for server side scripts, and includes the necessary libraries. The Graal native compilation feature is not used because it only provides a 5% increase in overall performance and requires specific builds for specific versions of the Graal VMs. Contact Cogix if interested.