Core: introduction
As stated in the Architecture:
Core functionality is considered functionality that does not or very loosely tie in to particular modules. It is functionality that has meaning on its own without dependencies, but is enriched by modules.
The core really implements the “engine” of Open Forms and hides all the implementation details. It should be fairly stable, but also continually allow for new feature additions, which is a challenging task!
The following Django apps are considered core functionality:
openforms.accounts
: (staff) user account managementopenforms.config
: application-wide configuration and defaultsopenforms.forms
: designing and building of formsopenforms.formio
: integration with the form.io frontend libraryopenforms.submissions
: persisting and handling of submitted form dataopenforms.variables
: persisting (intermediate) data into variables for further operations
Data model
The following is a simplified relationship diagram of the Django models that relates to forms:
Each Form
can have multiple FormStep
’s
defined, which acts as a proxy model to a FormDefinition
(as these can be reusable across forms). The FormDefinition
model
has a configuration
JSON field, holding the form.io configuration.
The submissions data model mirrors this model in some way:
A
Submission
is tied to aForm
.A
SubmissionStep
is tied to aFormStep
.A
SubmissionValueVariable
is tied to aFormVariable
.