Dynamic forms (eav)
They are used for defining and saving the extended attributes of selected entities:
SysSystem- linked to the systemsIdmIdentity- identities- … more will be added according to the implementation
Extended attributes are saved in the individual tables according to the entity which they are linked to ⇒ which is their owner (e.g. the entity SysSystemFormValue').
FormService serves for working with the extended attributes on the back-end.
On the front-end, the editing of dynamic forms is done by the component EavForm.
Dynamic forms support these data types with properties:
obligationreadonlymulti values- represented on the front-end by a textarea, where a line is a value (a new line separates the values)confidential- the values are stored in an encrypted storage). Stored values of these attributes - substitute characters only - are loaded on the front-end. The value can only be changed and determined whether it is filled in.
Adding the support of extended attributes for a new entity
- Adding an interface implementation FormableEntity to the new entity,
- creating a manager implementation by inheriting AbstractFormableService for the new entity,
- creating the entity by inheriting AbstractFormValue, which will represent the values of extended attributes for the new entity (owner),
- creating a repository by inheriting AbstractFormValueRepository for the values of the extended attributes,
- creating the manager by inheriting AbstractFormValueService for the values of the extended attributes,
- issuing a REST endpoint for saving the extended attributes from the FE - see controller,
- creating a service and redux manager communicating with REST - see manager
So far, the agenda for managing form definitions has not been implemented, therefore the procedure will be changed (and possibly simplified with regard to usage from the FE, which is now linked to a predefined form definition).
Agenda for working with forms
On the FE, there is not an agenda of forms - their definition and attributes. Each definition can contain zero or more attributes. To maintain the integrity, an interface UnmodifiableEntity has been created, which allows adding a flag that the entity has been created by the system and cannot be modified (or some of its attributes) and deleted (this logic now needs to be implemented manually into the relevant controllers), for example in IdmFormAttributeController.
It is necessary to be cautious when editing individual form attributes as the logic linked to this form can be rendered non-functional
Future development
- Adding DTO FormInstance for representing the form definition, the owner and the form values
- API for saving the owner and the eav form in one transaction