Table of Contents

Dynamic forms (eav)

Dynamic forms are used for:

Dynamic forms are supported for selected entities:

Dynamic form instances (values) are saved in the individual tables according to the entity which they are linked to ⇒ which is their owner (e.g. the entity IdmIdentityFormValue, IdmRoleFormValue).

FormService service 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 form attribute supports data types (persistentType):

with properties:

Dynamic form attribute can be rendered differently on frontend. Face type (faceType) property is used for choosing frontend renderer. Default renderer is chosen by persistent type (e.g. UUID → UUID).

Renderer is frontend component, superclass component AbstractFormAttributeRenderer is used for all renderer implementations. Renderer is responsible for IdmFormValue ⇔ input value transformation.

Renderers are registered in module's component-descriptor.js as single component with attributes:

All component descriptor features are supported. Read tutorial, how to create custom form attribute renderer.

Adding the support of extended attributes for a new entity

Backend

Frontend

Agenda for working with forms

On the FE, there is 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.

Data migration, when attribute's persistentType or confidential is changed is not supported now.

Common forms

Common forms is used for saving internal dynamic forms for: - report filters - long running task properties (comming soon) - authorization policiy properties (comming soon)

Form has to have form definition and owner, which can be an entity implementing FormableEntity interface. One owner can have more forms. When owner is deleted, then all forms have to be deleted to - override owner's service delete method properly. Form can be shared between owners - e.g. report filter can be used as input (properties) for long running task - this is the main reason, why common forms exists, don't use this common forms for storing extended attributes mentioned above (e.g. they will not be shown on frontend).

Future development