ANPASSUNG VON FORMULAREN

Formulare basieren intern grundsätzlich auf Formularobjekten (Klasse und Unterklasse von /PCH/CLA_CFW_FORM_ROOT). Anhand der Model-Klasse ist erkennbar, ob das Formular intern die 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 /PCH/CLA_CFW_MDL_CVE_FORM (oder einer Unterklasse) ab.

Anpassung über Model-BAdI
Die Erweiterung über ein Model-BAdI kann immer eingesetzt werden, auch wenn dies bei vorhandener Unterstützung der CVE nur bedingt sinnvoll ist. Das BAdI /PCH/CFW_BADI_FORM ist Teil des Erweiterungsspots /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 /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:

• Neue Felder hinzufügen
• Felder entfernen
• Feldeigenschaften ändern (z.B. Read Only Flag)

Strukturierung und Reihenfolge

Durch ProNovia werden verschiedene Standard-Views ausgeliefert. Jedes auf der Custom View Engine basierende Widget definiert die zu verwendende View statisch (Siehe Redefinition der Methode DEFINE_CUSTOM_VIEW_INT in der Model-Klasse). Gleichzeitig kann für jedes dieser Widgets im Customizing das zu verwendende Formular als Widget-Parameter in der Anwendung definiert werden.
Da die ausgelieferten Views bei jeder Produktaktualisierung überschrieben werden, muss die Custom View für eine kundenspezifische Anpassung in jedem Fall in den Kundennamensraum kopiert werden. Gleichzeitig muss im Customizing sichergestellt werden, dass das Widget diese neue Custom View verwendet.

Die verfügbaren Felder hängen von den sog. Feedern ab. Diese stellen eine Menge von Felder (und anderen Objekten wie z.B. Ikonen) zu Verfügung. Für die meisten ProNovia Business Objekte steht ein entsprechender Feeder zu Verfügung. Diese Feeder erzeugen, basierend auf den durch das entsprechende Business Objekt bereitgestellten Daten, pro Datenfeld ein CVE Element.
Wird eine Erweiterung der Oberfläche um neue Daten gewünscht, steht das Feld deshalb automatisch zu Verfügung, wenn dieses bereits durch das Business Objekt geliefert wird. Ist das Feld zwar Bestandteil der Haupttabelle des entsprechendes Objekts, aber wird durch das Business Objekt noch nicht bereitgestellt, dann kann durch eine einfache Erweiterung des Business Objekts das Feld verfügbar gemacht werden. Nach dem erneuten Generieren der Metadaten stehen im Editor CVE Elemente für die neu hinzugefügten Felder bereit.

Anpassung über Custom View BAdI
Soll das Formular nicht strukturell verändert werden, sondern nur Eigenschaften überschrieben werden (z.B. Labels), ist die Implementierung des BAdIs /PCH/CFW_CUSTOM_VIEW_ENGINE des Erweiterungsspots /PCH/CFW_CUSTOM_VIEW_ENGINE besser geeignet, da einerseits eine kundenspezifische Kopie einer View nicht mehr automatisch um neue Features erweitert wird und zudem bestimmte Eigenschaften auch nicht überschrieben werden können. Das BAdI kann mit Hilfe von Filter auf eine konkrete Anwendung oder eine bestimmte View eingeschränkt werden. Mit Hilfe des BAdIs können die folgenden Erweiterungen vorgenommen werden:

• Optionale Initialisierung der kundenspezifischen Daten (Methode INIT)
• Ändern sämtlicher Attribute eines Elements (Methode BIND)
• Behandeln einer Aktion (Methode HANDLE_ACTION)
• Erweiterung und Anpassung des Kontextmenüs (Methode BUILD_CONTEXT_MENU)
• Behandeln einer Kontextmenü-Funktion (Methode HANDLE_CONTEXT_MENU)

Eigene Feeder
Sollen in einem Formular zusätzliche Felder angezeigt werden, die nicht durch das Business Objekt und durch den entsprechenden Feeder bereitgestellt werden können, muss ein eigener Feeder implementiert werden. Ein kundenspezifischer Feeder muss von der Klasse /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.

1. Bereitstellen der eigenen Felder Mit der Methode RETRIEVE müssen alle Custom View Objekte statisch definiert werden. Die hier definierten Objekte können anschliessend im Designer verwendet werden. Die Attribute der jeweiligen Elemente müssen hier noch nicht abschliessend festgelegt werden, da diese zur Laufzeit durch den Feeder in Abhängigkeit vom aktuellen Kontext überschrieben werden können. Bei Ein-/Ausgabefeldern empfiehlt es sich die Klasse /PCH/CLA_CFW_CVO_DATA_VALUE zu verwenden, da diese grundsätzlich Oberflächen-neutral ist und im Designer der gewünschte Typ (Ausgabefeld, Eingabefeld, Dropdown, usw.) festgelegt werden kann. Die ID der Elemente hat eine sehr zentrale Bedeutung, da dieser zur Laufzeit wieder benötigt wird. Sie soll ebenfalls im Kundennamensraum sein.
2. Kontext prüfen Um festzustellen, ob der aktuelle Kontext für den Feeder relevant ist, wird die Methode IS_CONTEXT_RELEVANT aufgerufen. In dieser Methode ist zu prüfen, ob der Kontext für den Feeder relevant ist. Der Kontext wird dabei über den Parameter IO_CONTEXT übergeben. Es handelt sich dabei in aller Regel um eine Business Objekt Instanz. Ist der Kontext relevant, wird der vollständige Kontext anschliessend automatisch mit der Methode SET_CONTEXT_ENH_INT gesetzt. Anschliessend steht der vollständige Kontext im Attribut MO_CONTEXT zu Verfügung. Handelt es sich beim Kontext um ein Business Objekt, dann wird dieses zudem im Attribut MO_BO_CONTEXT bereitgestellt. In den Attributen MV_BO_VALID_FROM und MV_BO_VALID_TO wird der Gültigkeitszeitraum gesetzt.
3. Daten initialisieren Bevor die eigentlichen Felder aufbereitet werden, wird die Methode INIT aufgerufen, mit dem sinnvollerweise die Daten vollständig eingelesen werden, weil im Anschluss jedes Feld einzeln prozessiert wird.
4. Daten binden Die Methode BIND_CUSTOM_VIEW_OBJECT wird zur Laufzeit für jedes einzelne Element der View aufgerufen. Anhand der ID lässt sich das Element eindeutig identifizieren. Zu diesem Zeitpunkt können sämtliche Attribute des Elements (Wert, Eingabebereitschaft, Sichtbarkeit, usw.) gesetzt werden.
5. Daten aktualisieren Wenn eine Aktualisierung der Daten angefordert wird, dann wird intern die Methode REFRESH aufgerufen. Die intern gehaltenen Daten müssen nun aktualisiert werden.

Daten abbauen Wenn das Formular freigegeben wird, dann sollen allfällige Daten (v.a. Objektinstanzen) freigegeben werden. Dies geschieht in der Methode FREE.

Für die Feeder steht eine zentrale Service Klasse /PCH/CL_CFW_CVE_SERVICES zu Verfügung. Diese Klasse beinhaltet insbesondere für das Bereitstellen und Binden der Daten die folgenden Methoden:

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

BIND_STRUCTURE_DATA, Bindet vollautomatisch ein Element einer Struktur. Dabei wird das "Hauptobjekt", aber auch das Label oder ein Bezeichnungs-Objekt unterstützt.