Verschiedene ProFramework-Widgets basieren auf der Various ProFramework widgets are based on the ProNovia Custom View Engine. Die The Custom View Engine entkoppelt die Darstellung (das Layout und teilweise den Inhalt) eines Widgets und lagert die entsprechende Definition in ein sogenanntes Formular decouples the display (the layout and partly the content) of a widget and offloads the corresponding definition into a so-called form (Custom View) aus.
Das Formular definiert entsprechend, was in einem Widget angezeigt wird, und wie es angezeigt wird. Damit ist es möglich, den Inhalt und die Anordnung des Inhalts in einem Widget modifikationsfrei anzupassen.
Folgende Widgets unterstützen Formulare:
das Widget Dokumentdaten
die Widgets Materialdaten (Mandanten, Werks- und Vertriebsdaten)
das Widget Daten
Grundsätzlich wird zwischen zwei Arten von Formularen unterschieden:
Formulare für Baumdarstellungen (Widget Daten)
...
Technisch gesehen ist ein Formular eine hierarchische Struktur aus gebundenen und/oder nicht gebundenen Elementen (Custom View Objects). Diese Struktur sowie die aktuell angezeigten Daten werden zur Laufzeit durch das System in die entsprechende Darstellung übersetzt. Gebundene Elemente sind Elemente, deren Eigenschaften automatisch vom System gefüllt werden. Nicht gebundene Elemente (in der Regel Container) sind Elemente, deren Eigenschaften statisch definiert sind.
Zu den gebundenen Eigenschaften zählen in der Regel:
Bei Bezeichnerfeldern: Sichtbarkeit
Bei Eingabefeldern: Sichtbarkeit, Editierbarkeit und Feldinhalt
Bei Textfeldern: Sichtbarkeit und Feldinhalt
Bei Ikonen: Sichtbarkeit, Ikone und Tooltip
Tabellen: Anzahl Zeilen, Editierbarkeit, verfügbare Funktionen
Ansicht der Formularstruktur im Formulareditor
...
Technisch bedingt unterstützt nicht jeder Formulartyp jeden Elementtyp oder jede Eigenschaft. So unterstützen Baumformulare nur Container (Knoten) sowie Bezeichner-, Ikonen- und Textfelder.
| Note |
|---|
AFW Formulare sind Entwicklungsobjekte und können nur in Mandanten mit entsprechenden Einstellungen geändert werden und benötigen ggf. einen entsprechenden Transportauftrag für den Transport in Folgesysteme. |
Gebundene und nicht gebundene Elemente
Gebundene Elemente besitzen eine definierte Semantik, welche über das Binding bereitgestellt wird. Das Binding definiert dabei den Datenanbieter (bspw Feeder MARA), eine Klassifizierung sowie den Inhalt, den das Element repräsentiert.
So definiert beispielsweise das Binding F@@@@MARA_MATERIAL_NUMBER_LBL den Bezeichner der Materialnummer während F@@@@MARA_MATERIAL_NUMBER die Materialnummer an sich definiert. Bei gebundenen Feldern werden relevante Daten wie z.B. Inhalt, Zustand (Sichtbarkeit, Änderbarkeit) automatisch vom System gefüllt, sofern diese nicht im Formular anderweitig angegeben wurden.
Die Eigenschaften von nicht gebundenen Elementen werden ausschliesslich im Formular bestimmtThe 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.