Various ProFramework widgets are based on the ProNovia Custom View Engine. The Custom View Engine decouples the display (the layout and partly the content) of a widget and offloads the corresponding definition into a so-called form (Custom View).
The form defines accordingly what is displayed in a widget and how it is displayed. This makes it possible to customize the content and arrangement of the content in a widget without modification.
The following widgets support forms:
the Document Data widget
the Material Data widget (client, plant and sales data)
the widget Data
Basically, a distinction is made between two types of forms:
Forms for tree representations (widget data)
Mask forms (e.g. widget document data or material data).
Technically, a form is a hierarchical structure of bound and/or unbound elements (Custom View Objects). This structure, as well as the currently displayed data, is translated into the appropriate representation by the system at runtime. Bound elements are elements whose properties are automatically filled by the system. Unbound elements (usually containers) are elements whose properties are defined statically.
Bound properties usually include:
For identifier fields: visibility
For input fields: visibility, editability and field content
For text fields: visibility and field content
For icons: Visibility, icon, and tooltip.
Tables: Number of rows, editability, available functions
View of the form structure in the form editor
For technical reasons, not every form type supports every element type or property. For example, tree forms support only containers (nodes) and identifier, icon and text fields.
AFW forms are development objects and can only be modified in clients with appropriate settings and may require an appropriate transport request for transport to subsequent systems.
Bound and unbound elements
Bound elements have a defined semantics, which is provided by the binding. The binding defines the data provider (e.g. feeder MARA), a classification and the content that the element represents.
For example, the binding F@@@@MARA_MATERIAL_NUMBER_LBL defines the identifier of the material number while F@@@@MARA_MATERIAL_NUMBER defines the material number itself. For bound fields, relevant data such as content, state (visibility, modifiability) are automatically filled by the system unless otherwise specified in the form.
The properties of unbound elements are determined exclusively in the form.