Formulare basieren intern grundsätzlich auf Formularobjekten (Klasse und Unterklasse von Forms are internally based on form objects (class and subclass of /PCH/CLA_CFW_FORM_ROOT). Anhand der Model-Klasse ist erkennbar, ob das Formular intern die The Model class indicates whether the form internally uses the Custom View Engine verwendet, welche die Gestaltung der Oberfläche in eine sog. Custom View auslagert. Sobald die Custom View Eingine unterstützt wird, leitet die Model-Klasse von der Klasse , which outsources the design of the interface to a so-called Custom View. As soon as the Custom View engine is supported, the Model class derives from the /PCH/CLA_CFW_MDL_CVE_FORM (oder einer Unterklasse) abclass (or a subclass).
...
...
Customization via Model-BAdI
Die Erweiterung über ein The extension via a Model-BAdI kann immer eingesetzt werden, auch wenn dies bei vorhandener Unterstützung der CVE nur bedingt sinnvoll ist. Das can always be used, even if this is only conditionally useful with existing support of the CVE. The BAdI /PCH/CFW_BADI_FORM ist Teil des Erweiterungsspots is part of the extension spot /PCH/CFW_WIDGET_FORM. Das BAdI unterstützt Filter, um die Implementierung auf eine konkrete Anwendung und/oder ein konkretes Widget einzuschränken.
Das BAdI-Interface The BAdI supports filters to restrict the implementation to a concrete application and/or a concrete widget.
The BAdI interface /PCH/IF_CFW_BADI_FORM beinhaltet verschiedene Methoden, mit denen sowohl im Widget, wie auch in der Model-Klasse eingegriffen werden kann. Die Methode CHANGE_FORM enthält als Parameter CO_FORM den Wurzelcontainer, indem beliebige Änderungen vorgenommen werden können. .
Anpassung der Custom View
Sobald ein Formular die Custom View Engine verwendet, erfolgt die Oberflächen-Definition nicht im ABAP Code sondern mit Hilfe einer auf XML basierenden Definition, für die ein umfangreicher Editor zu Verfügung steht. Mit Hilfe dieses Editors kann die gesamte Oberflächen-Definition geändert werden:
...
| Im Handbuch ProFramework Integration & Enhancement ist eine vollständige Anleitung für den visuellen Editor der Custom View Engine verfügbar. |
...
contains various methods that can be used to intervene in the widget as well as in the model class. The method CHANGE_FORM contains as parameter CO_FORM the root container, in which arbitrary changes can be made.
Customization of the Custom View
As soon as a form uses the Custom View Engine, the interface definition is not done in ABAP code but with the help of a definition based on XML, for which an extensive editor is available. With the help of this editor, the entire interface definition can be changed:
Add new fields
Remove fields
Change field properties (e.g. read only flag)
Structure and sequence
Various default views are delivered by ProNovia. Each widget based on the Custom View Engine statically defines the view to be used (See Redefinition of the DEFINE_CUSTOM_VIEW_INT method in
...
the Model
...
| Sobald die Custom View kopiert wurde, fliessen zukünftige Änderungen am Standard nicht mehr in die Kundenkopie ein. Vor einer allfälligen Erweiterung über ein kundenspezifische View sollte deshalb geprüft werden, ob die Verwendung des Custom View Engine BAdIs nicht die einfachere Lösung ist. |
...
| Zur Laufzeit behandelt der entsprechende Feeder jedes einzelne CVE Element. Dabei wird einerseits der Feldwert abgefüllt, es werden aber auch weitere Eingenschaften geschrieben (z.B. die Änderbarkeit von Feldern). Entsprechend kann es sein, dass in der Custom View gesetzte Eigenschaften überschrieben werden. Das Setzen der Eigenschaft ist in diesem Fall nicht über den Designer möglich, sondern muss durch ein BAdI erfolgen (siehe unten). |
...
class). At the same time, for each of these customizing widgets, the form to be used can be defined as a widget parameter in the application.
Since the delivered views are overwritten with every product update, the custom view must be copied to the customer namespace for customization in any case. At the same time, it must be ensured in Customizing that the widget uses this new Custom View.
| Info |
|---|
Once the custom view has been copied, future changes to the standard no longer flow into the customer copy. Before a possible extension via a custom view, it should therefore be checked whether the use of the Custom View Engine BAdI is not the simpler solution. |
The available fields depend on the so-called feeders. These provide a set of fields (and other objects like icons). For most ProNovia business objects a corresponding feeder is available. These feeders create one CVE element per data field, based on the data provided by the corresponding business object.
Therefore, if an extension of the interface with new data is desired, the field is automatically available if it is already provided by the business object. If the field is part of the main table of the corresponding object, but is not yet provided by the business object, then the field can be made available by a simple extension of the business object. After the metadata has been regenerated, CVE elements for the newly added fields are available in the editor.
| Note |
|---|
At runtime, the corresponding feeder handles each individual CVE element. On the one hand the field value is filled, but also further properties are written (e.g. the changeability of fields). Accordingly it can be that properties set in the Custom View are overwritten. In this case, the property cannot be set via the Designer, but must be set via a BAdI (see below). |
Customization via Custom View BAdI
If the form is not to be changed structurally, but only properties are to be overwritten (e.g. labels), the implementation of the BAdI /PCH/CFW_CUSTOM_VIEW_ENGINE
...
of the extension spot /PCH/CFW_CUSTOM_VIEW_ENGINE
...
is more suitable, since on the one hand a customer-specific copy of a view is no longer automatically extended with new features and, moreover, certain properties cannot be overwritten either. The BAdI can be restricted to a specific application or a specific view using filters. The following enhancements can be made with the help of the BAdI:
Optional initialization of customer-specific data (method INIT)
Changing all attributes of an element (method BIND)
Handling of an action (method HANDLE_ACTION)
Extension and adaptation of the context menu (method BUILD_CONTEXT_MENU)
- Behandeln einer Kontextmenü-Funktion (Methode
Handling a context menu function (method HANDLE_CONTEXT_MENU)
...
Own feeders
If additional fields are to be displayed in a form that cannot be provided by the business object and by the corresponding feeder, a custom feeder must be implemented. A custom feeder must be derived from the /PCH/CLA_CFW_CVE_FEEDER abgeleitet werden.
Nachfolgend wird ausschliesslich das Bereitstellen von neuen Feldern beschrieben. Grundsätzlich unterstützt ein Feeder auch die Aktualisierung von Daten oder das Bereitstellen und Ausführen von Aktionen. Die folgenden Methoden müssen redefiniert und mit eigener Logik versehen werden.
...
class.
In the following, only the provisioning of new fields is described. Basically, a feeder also supports updating data or providing and executing actions. The following methods must be redefined and provided with own logic.
Providing custom fields With the RETRIEVE method, all custom view objects must be defined statically. The objects defined here can then be used in the Designer. The attributes of the respective elements do not have to be defined conclusively here, since these can be overwritten at runtime by the feeder depending on the current context. For input/output fields, it is recommended to use the class /PCH/CLA_CFW_CVO_DATA_VALUE
...
, since this is basically interface-neutral and the desired type (output field, input field, dropdown, etc.) can be specified in the designer. The ID of the elements has a very central meaning, since this is needed again at runtime. It should also be in the customer namespace.
Check context To determine if the current context is relevant for the feeder, the method IS_CONTEXT_RELEVANT is called. In this method it is to be checked whether the context is relevant for the feeder. The context is passed by the parameter IO_CONTEXT. This is usually a business object instance. If the context is relevant, the complete context is then automatically set with the method SET_CONTEXT_ENH_INT
...
. Afterwards the complete context is available in the attribute MO_CONTEXT
...
. If the context is a business object, it is also provided in the MO_BO_CONTEXT
...
attribute. In
...
the attributes MV_BO_VALID_FROM
...
and MV_BO_VALID_TO
...
the validity period is set.
Initialize data Before the actual fields are prepared, the method INIT is called, with which the data are read in completely, because afterwards each field is processed individually.
Bind data The method BIND_CUSTOM_VIEW_OBJECT
...
| Ein Feeder wird immer genau für einen Kontext aufgerufen. Wird in der Oberfläche das Objekt gewechselt, dann wird immer ein neues Formular initialisiert und neue Feeder-Instanzen erzeugt. |
...
is called at runtime for each individual element of the view. The element can be uniquely identified by its ID. At this time, all attributes of the element (value, ready for input, visibility, etc.) can be set.
Update data If an update of the data is requested, then internally the method REFRESH is called. The internally held data must now be updated.
Release data If the form is released, then any data (especially object instances) should be released. This is done in the method FREE.
| Info |
|---|
One feeder is always called for exactly one context. If the object is changed in the interface, then a new form is always initialized and new feeder instances are created. |
A central service class /PCH/CL_CFW_CVE_SERVICES
...
is available for the feeders. This class contains the following methods, in particular for providing and binding the data:
RETRIEVE_FROM_TYPE,
Erzeugt für eine Struktur pro Feld ein CVE Objekt inkl. einem Label-Objekt und allenfalls einem Beschreibungs-Objekt, wenn ein Fremdschlüssel vorhanden ist (z.B. die Bezeichnung eines Labors)Creates for a structure per field a CVE object incl. a label object and if necessary a description object, if a foreign key is present (e.g. the designation of a laboratory).
BIND_STRUCTURE_DATA,
Bindet vollautomatisch ein Element einer Struktur. Dabei wird das "Hauptobjekt", aber auch das Label oder ein Bezeichnungs-Objekt unterstützt.Binds an element of a structure fully automatically. The "main object" is supported, but also the label or a description object.
| Info |
|---|
Ideally, the fields provided by the customer-specific are managed via a structure. In this case, the implementation effort can be reduced to an absolute minimum using the methods described above. |