...
The form framework works with the MVC pattern (= model, view. , controller) which separates data, view and logic parts from each other.
In order to cover this pattern and tp to create such a form in PIPEFORCE, you need these documents in your app:
...
The model and the view documents will be passed to a loaded by the form generator which is implemented in the portal. It will render and show a form to the user based on the input documents:
Drawio | ||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
After the user has edited the form and clicked the submit button of the form, the form fields and their values will be rendered to a JSON document called the “form output model” (output data). This model is then stored to the output location, which is typically a as property in the property store.
The property store then sends fires a property.
create created
event. A pipeline can listen to this event and handle the form submit controller logic accordingly. For this, also see how to create an event listening pipeline, here: Events .
Let’s have a look to all of these parts step by step below.
The Form Model
The Form Model is a JSON document which provides the data to be displayed in the form. It is the central part of the form framework: The whole framework is about loading this model (A), displaying it in a form (B), validating it, merging the data from the form back to the model (C) and storing the final model to some target sink. The structure of the input and output model JSON document is always defined by the same Form Schema (D).
The Input Form Model
There can be an optional input form model (A) which is the data to be shown initially to a form. For example in case data will be loaded from a database in order to edit it in the form, then this data from the database will become the input model to the form. The model must comply with the Form Schema (D).
...