vorgefertigte ALV-Klasse mit ZTabelle und Z-Struktur

Re: vorgefertigte ALV-Klasse mit ZTabelle und Z-Struktur

Hi!

JonPiero hat geschrieben:Dazu soll eine Z-Tabelle erstellt werden, in welcher die Spalteninformationen hinterlegt sind, also beispielsweise eine Programm-ID und eine ALVID und die Feldnamen.
Desweiteren soll eine z-Struktur angelegt werden in der die wesentlichen Elemnte hinterlegt sind also beispielsweise der Header, das layout oder die Display-settings.

Entweder versteh ich die Anforderung nicht, oder du bzw. dein Arbeitgeber weiß nicht wie man (S)ALVs richtig einsetzt. Die Funktion die du hier beschreibst ist die normale Layout-Verwaltung die bei jedem (S)ALV automatisch dabei ist. Wichtig ist, dass beim ALV der Parameter I_SAVE der Methode SET_TABLE_FOR_FIRST_DISPLAY gesetzt wird. Beim SALV ist die Funktion IMHO automatisch aktiv. Ansonsten kann man über GET_LAYOUT und SET_SAVE_RESTRICTION die Einstellungen auch ändern.

Was die Wrapper-Klasse anbelangt, ist es sicher kein schlechter Ansatz, immer wieder kehrende Aufgaben zu kapseln. Nur da solltet ihr euch eine bessere Logik überlegen, als den ganzen Kram der schon in der Layoutverwaltung abgelegt wird, nochmal in eigenen Z-Tabellen zu speichern.
Einige Denkanstöße aus meiner "Wrapper-Klasse":

• Abhängig vom Datenelement eigene Eigenschaften setzten. (z.B.: Bei Timestamps die richtige EDIT_MASK)
• Ein- und Ausschalten von Zusatzfunktionen wie Zeilen-/Zelleneinfärbung (inkl. Generierung einer dynamischer Ausgabestruktur zur Laufzeit damit man das bei der Strukturdefinition im DDIC nicht berücksichtigen muss)
• Handling von Drop-Down-Feldern mit Handler und internem/externem Wert.
• Automatisches F4-Handling je nach Datenelement (z.B.: F4_CLOCK bei Zeitfeldern.)

lg ADT

Re: vorgefertigte ALV-Klasse mit ZTabelle und Z-Struktur

Naja, eher die wiederkehrenden Abläufe automatisieren, wie z.B. Anpassen des Feldkataloges aufgrund von Vorgaben.
Da müssen oft mehrere Methoden hintereinander aufgerufen werden, somit fast man das zusammen, damit man nur noch einen Methodenaufruf benötigt.
Am Besten du schaust dir mal an, was so in deiner Firma rund um die ALVs entwickelt wurde. Oft erkennt man da schon einige Muster heraus die immer wieder auftreten und es somit Sinn macht, dafür eine eigene Methode zu haben.

Ich hab auch noch mal über die Z-Tabelle nachgedacht und sie wäre insofern interessant, als dass man da z.B. aufgrund von Tabellen-/Feld- oder Datenelement-Namen Voreinstellungen für den Aufbau des Feldkataloges treffen kann.
Um im Standard SAP-Beispiel mit SFLIGHT zu bleiben: Wenn im ALV das Feld CARRID angezeigt wird, soll die Spalten einen Hotspot erhalten und bei Klick darauf ein Fenster aufgehen, das den SCARR-Eintrag dazu einblendet.
Was IMHO keinen Sinn macht, ist in dieser Tabelle auch Programm-ID und eine ALVID zu speichern, weil man damit dann die Layout-Verwaltung nachbaut.

Anfangs wird die Wrapper-Klasse nur ein kleines Set an Methoden beinhalten die sich aber sicherlich mit jeder neuen Implementierung langsam erweitern werden.
Wichtig ist nur, dass ihr intern die Vereinbarung trefft, dass fortan nur noch die Wrapper-Klasse verwendet wird. Sobald neue Anforderungen eine Änderung notwendig machen, wird die beste Lösung dafür dann analysiert und die Klasse dann dementsprechend erweitert. Nur solltet ihr hier ein für euch passendes Entwurfsmuster wählen um nicht am Ende mit einer unwartbaren Monster-Implementierung herumhantieren zu müssen.
http://de.wikipedia.org/wiki/Entwurfsmuster

lg
ADT