Customizing of Forms

Forms are internally based on form objects (class and subclass of /PCH/CLA_CFW_FORM_ROOT). The Model class indicates whether the form internally uses the Custom View Engine, 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 class (or a subclass).

Customization via Model-BAdI

The extension via a Model-BAdI can always be used, even if this is only conditionally useful with existing support of the CVE. The BAdI /PCH/CFW_BADI_FORM is part of the extension spot /PCH/CFW_WIDGET_FORM. 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 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 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.

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.

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)
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 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 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.

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, 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, Binds an element of a structure fully automatically. The "main object" is supported, but also the label or a description object.