Datentypen von Klassenattributen bestimmen
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo erstmal,
dies ist mein erster Post und ich möchte mich kurz vorstellen. Ich bin Student der Wirtschaftsinformatik und schreibe gerade an einer Studienarbeit, die das Ziel hat, einen editierbaren ALV auf Basis eines MVC Patterns zu realisieren.
Zur Zeit hänge ich an dem Problem, dass ich zur Instantiierung einiger Datenobjekte den Datentyp der Attribute der ModellKlasse benötige. Da im besagten Pattern die ControllerKlasse nichts von der ModellKlasse weiß (wissen darf) muss die Analyse zur Laufzeit erfolgen. Ich habe mir schon die Klasse cl_abap_classdescr angeschaut, welche mir jedoch nicht sonderlich weitergeholfen hat.
Hat jemand von euch die Idee, wie man das Problem angeht?
Viele Dank schon mal.
Paddy
dies ist mein erster Post und ich möchte mich kurz vorstellen. Ich bin Student der Wirtschaftsinformatik und schreibe gerade an einer Studienarbeit, die das Ziel hat, einen editierbaren ALV auf Basis eines MVC Patterns zu realisieren.
Zur Zeit hänge ich an dem Problem, dass ich zur Instantiierung einiger Datenobjekte den Datentyp der Attribute der ModellKlasse benötige. Da im besagten Pattern die ControllerKlasse nichts von der ModellKlasse weiß (wissen darf) muss die Analyse zur Laufzeit erfolgen. Ich habe mir schon die Klasse cl_abap_classdescr angeschaut, welche mir jedoch nicht sonderlich weitergeholfen hat.
Hat jemand von euch die Idee, wie man das Problem angeht?
Viele Dank schon mal.
Paddy
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4394 / 223 /
1182
)
»
hi!
Da hast du ja eh schon das passende gefunden!
CL_ABAP_CLASSDESCR stellt dir zur Laufzeit alle möglichen Informationen einer Klasse zur Verfügung.
Wo genau kommst du damit nicht weiter?
lg ADT
EDIT:
Hier eine kurze Aufruf-Reihenfolge wie man zu den Datentypen der Attribute kommt
Da hast du ja eh schon das passende gefunden!
CL_ABAP_CLASSDESCR stellt dir zur Laufzeit alle möglichen Informationen einer Klasse zur Verfügung.
Wo genau kommst du damit nicht weiter?
lg ADT
EDIT:
Hier eine kurze Aufruf-Reihenfolge wie man zu den Datentypen der Attribute kommt
Code: Alles auswählen.
lr_classdescr ?= CL_ABAP_TYPEDESCR=>DESCRIBE_BY_OBJECT_REF( ... ).
LOOP AT lr_classdescr->attributes ASSIGNING <ls_attribute>.
lr_datadescr = lr_classdescr->get_attribute_type( <ls_attribute>-name ).
ld_type = lr_datadescr->get_relative_name( ). "Wenn es sich um DDIC Datenelement handelt
CASE lr_datadescr->type_kind. "Wenn es sich um kein DDIC Datenelement handelt
WHEN cl_abap_typedescr=>typekind_char.
...
ENDCASE.
ENDLOOP.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4394 / 223 /
1182
)
»
Da die Bestimmung zur Laufzeit etwas aufwändig ist und auch der dyn. Methodenaufruf, würde ich dir (nachdem ich jetzt eine Nacht darüber geschlafen habe) aber einen anderen Weg vorschlagen:
Überleg dir ob es nicht sinnvoller wäre, eine zweite Vererbungslinie mit Interfaces einzuführen.
Dann musst du innerhalb deines Controllers die tatsächliche Modellklasse nicht bis ins kleinste Detail kennen, aber die Modellklasse muss das Interface XYZ implementieren um vom Controller erkannt zu werden. Wie die einzelenen Methoden des Controllers dann auf das Modell reagieren bestimmst du je Klasse.
Ich nehme mal an du willst ein austauschbares Modell, damit du unterschiedlichste Tabellen im ALV (Viewer) anzeigen kannst, wobei die Steuerung (Controller) ebenfalls generisch erfolgen soll (Hinzufügen/Ändern/Löschen/Key-Prüfungen usw.).
Da würde ich das Modell wirklich nur als Interface sehen, dass du je Datenquelle (DB-Tabelle/Interne Tabelle/Whatever)
Darauf aufbauend kannst du ja dennoch eine Klassenvererbung aufsetzten. z.B. eine Grundklasse für den allgemeinen DB-Zugriff.
Ich hab sowas ähnliches auch schon umgesetzt, aber leider nicht streng nach MVC
Bei mir ist Modell und Controller in einem, wobei intern immer eine generische Tabelle mittels Sessions verwaltet wird und je nach Ableitung die Datenquelle bestimmt wird. Den Viewer hab ich da mal außen vor gelassen. Ich hab zwar einen ALV Viewer mit einigen Zusatzfunktionen, aber der ist nicht mit der Datenklasse "kombiniert" und daher kann ich beide je nach Einsatzzweck verwenden. Die Schnittstelle zwischen den Zweien ist nachwievor eine interne Tabelle wobei ich hinzufügen/Ändern/löschen im ALV immer mit einem Vorher/Nachher Vergleich ermitteln muss. Andererseits verwenden wir nur in sehr wenigen Fällen das editierbare ALV, daher war das ursprünglich kein Problem, aber inzwischen denke ich mir oft: Hätt ich doch damals ...
Ne, ist nicht so schlimm, aber dieser Vorher/Nachher vergleich wird beim ALV immer notwendig sein, da man schwer sagen kann WIE der User die Daten verändert hat. Ich denke da jetzt vor allem an STRG+Y / STRG+C /STRG+V aus einer anderen Tabelle usw.
Hoffe da waren einige Anregungen für dich dabei.
lg ADT
Überleg dir ob es nicht sinnvoller wäre, eine zweite Vererbungslinie mit Interfaces einzuführen.
Dann musst du innerhalb deines Controllers die tatsächliche Modellklasse nicht bis ins kleinste Detail kennen, aber die Modellklasse muss das Interface XYZ implementieren um vom Controller erkannt zu werden. Wie die einzelenen Methoden des Controllers dann auf das Modell reagieren bestimmst du je Klasse.
Ich nehme mal an du willst ein austauschbares Modell, damit du unterschiedlichste Tabellen im ALV (Viewer) anzeigen kannst, wobei die Steuerung (Controller) ebenfalls generisch erfolgen soll (Hinzufügen/Ändern/Löschen/Key-Prüfungen usw.).
Da würde ich das Modell wirklich nur als Interface sehen, dass du je Datenquelle (DB-Tabelle/Interne Tabelle/Whatever)
Darauf aufbauend kannst du ja dennoch eine Klassenvererbung aufsetzten. z.B. eine Grundklasse für den allgemeinen DB-Zugriff.
Ich hab sowas ähnliches auch schon umgesetzt, aber leider nicht streng nach MVC
Bei mir ist Modell und Controller in einem, wobei intern immer eine generische Tabelle mittels Sessions verwaltet wird und je nach Ableitung die Datenquelle bestimmt wird. Den Viewer hab ich da mal außen vor gelassen. Ich hab zwar einen ALV Viewer mit einigen Zusatzfunktionen, aber der ist nicht mit der Datenklasse "kombiniert" und daher kann ich beide je nach Einsatzzweck verwenden. Die Schnittstelle zwischen den Zweien ist nachwievor eine interne Tabelle wobei ich hinzufügen/Ändern/löschen im ALV immer mit einem Vorher/Nachher Vergleich ermitteln muss. Andererseits verwenden wir nur in sehr wenigen Fällen das editierbare ALV, daher war das ursprünglich kein Problem, aber inzwischen denke ich mir oft: Hätt ich doch damals ...
Ne, ist nicht so schlimm, aber dieser Vorher/Nachher vergleich wird beim ALV immer notwendig sein, da man schwer sagen kann WIE der User die Daten verändert hat. Ich denke da jetzt vor allem an STRG+Y / STRG+C /STRG+V aus einer anderen Tabelle usw.
Hoffe da waren einige Anregungen für dich dabei.
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
Paddy
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo A-D-T,
vielen Dank für deine Mühe und deinen gerade ausgeführten Denkanstoß. So etwas in der Art hatte ich auch im Hinterkopf und bin die ganze Zeit auch schon am rumtüfteln aber irgendwie komme ich der Sache nicht ganz auf die Spur. Ich habe mal ein UML Diagramm gemalt um meine Idee etwas zu verdeutlichen. Mein Problem ist nämlich, dass der Typ der Modell-Klasse der Controll Klasse bekannt sein muss, um dieses zu instantiieren. Ich dachte mir darauf hin, dass in der Controll-Klasse den Type des Interfaces angebe um die konkrete Modell-Klasse zu instantiieren aber genau hier beginnen meine Probleme.
Die Businesslogik im Modell soll erstmal alle Daten aus der SFLIGHT Tabelle in eine interne speichern. Dies ist ja möglich in dem ich diese itab (mt_outtab) mit Type ref data deklariere. Bei den Methoden stoße ich aber auf Probleme.. Bei den gettern und settern im Interface müssen die Parameter typisiert werden, wobei ich generische Parameter bräuchte. Meine eigentliche Frage ist also: Wie muss ich das Interface und wie die konkrete Klasse aufbauen?
Ist das, was ich vorhabe designtechnisch überhaupt möglich? Wäre super, wenn du etwas dazu sagen könntest.
Vielen dank und gute Nacht.....
vielen Dank für deine Mühe und deinen gerade ausgeführten Denkanstoß. So etwas in der Art hatte ich auch im Hinterkopf und bin die ganze Zeit auch schon am rumtüfteln aber irgendwie komme ich der Sache nicht ganz auf die Spur. Ich habe mal ein UML Diagramm gemalt um meine Idee etwas zu verdeutlichen. Mein Problem ist nämlich, dass der Typ der Modell-Klasse der Controll Klasse bekannt sein muss, um dieses zu instantiieren. Ich dachte mir darauf hin, dass in der Controll-Klasse den Type des Interfaces angebe um die konkrete Modell-Klasse zu instantiieren aber genau hier beginnen meine Probleme.
Die Businesslogik im Modell soll erstmal alle Daten aus der SFLIGHT Tabelle in eine interne speichern. Dies ist ja möglich in dem ich diese itab (mt_outtab) mit Type ref data deklariere. Bei den Methoden stoße ich aber auf Probleme.. Bei den gettern und settern im Interface müssen die Parameter typisiert werden, wobei ich generische Parameter bräuchte. Meine eigentliche Frage ist also: Wie muss ich das Interface und wie die konkrete Klasse aufbauen?
Ist das, was ich vorhabe designtechnisch überhaupt möglich? Wäre super, wenn du etwas dazu sagen könntest.
Vielen dank und gute Nacht.....
Du hast keine ausreichende Berechtigung, um die Dateianhänge dieses Beitrags anzusehen.
Beitrag
von a-dead-trousers (Top Expert / 4394 / 223 /
1182
)
»
hi!
naja... hmmm... Du könntest in der Interfacebeschreibung deines Modells die zur Datentabelle zugehörigen Type-Handles (CL_ABAP_STRUCTDESCR/CL_ABAP_TABLEDESCR) zur Verfügung stellen. Dann weiß jede der beteiligten Klassen womit sie es zu tun hat.
Bei Getter und Setter kannst du durchaus auch generische Datentypen (z.B. ANY / ANY TABLE / INDEX TABLE / usw.) verwenden. Nur halt nicht als RETURN-Parameter sondern nur als IMPORTING/EXPORTING/CHANGING.
Das Instanziieren kannst du ja auch so lösen, dass dem Controller beim Create die richtige Modellklasse zugewiesen werden muss.
Entweder vorher instanziert oder per Name.
Wenn per Name kannst du Objekte mit ( )-Syntax anlegen.
lg ADT
naja... hmmm... Du könntest in der Interfacebeschreibung deines Modells die zur Datentabelle zugehörigen Type-Handles (CL_ABAP_STRUCTDESCR/CL_ABAP_TABLEDESCR) zur Verfügung stellen. Dann weiß jede der beteiligten Klassen womit sie es zu tun hat.
Bei Getter und Setter kannst du durchaus auch generische Datentypen (z.B. ANY / ANY TABLE / INDEX TABLE / usw.) verwenden. Nur halt nicht als RETURN-Parameter sondern nur als IMPORTING/EXPORTING/CHANGING.
Das Instanziieren kannst du ja auch so lösen, dass dem Controller beim Create die richtige Modellklasse zugewiesen werden muss.
Entweder vorher instanziert oder per Name.
Wenn per Name kannst du Objekte mit ( )-Syntax anlegen.
Code: Alles auswählen.
CREATE OBJECT ... TYPE (...).
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
hallo,
Vielen Dank und Grüße
Paddy
Könntest du das ganauer erklären? Ich kann mir gerade nichts darunter Vorstellen. Ich habe es jetzt so gelöst, dass ich im Interface ein Attribut mit Referenz auf Data anlege, welches ich in der Implentierung mit dem konkreten Typ instantiiere.Du könntest in der Interfacebeschreibung deines Modells die zur Datentabelle zugehörigen Type-Handles (CL_ABAP_STRUCTDESCR/CL_ABAP_TABLEDESCR) zur Verfügung stellen.
Vielen Dank und Grüße
Paddy
Beitrag
von a-dead-trousers (Top Expert / 4394 / 223 /
1182
)
»
und zusätzlich zu diesem Attribut brauchst du auch noch die Beschreibung wie es aufgebaut ist.
Also ein weiteres Attribut vom Typ CL_ABAP_DATADESCR.
Damit kann dieses Interface unter dem Attribut DATA Daten vom Typ Tabelle/Struktur oder Element ablegen und mit dem CL_ABAP_DATADESCR hast du die Information über den Aufbau der Daten.
Um jetzt aus CL_ABAP_DATADESCR die Informationen zu einer Tabelle zu ermitteln, musst du nur Abfragen ob es sich tatsächlich um einen Tabellentyp handelt und dann die CL_ABAP_DATADESCR auf CL_ABAP_TABLEDESCR casten. Oder wenn du immer davon ausgehen kannst, dass hier Tabellen abgelegt werden kannst du gleich die CL_ABAP_TABLEDESCR verwenden.
Siehe dazu auch meinen Codeschnippsel.
lg ADT
Also ein weiteres Attribut vom Typ CL_ABAP_DATADESCR.
Damit kann dieses Interface unter dem Attribut DATA Daten vom Typ Tabelle/Struktur oder Element ablegen und mit dem CL_ABAP_DATADESCR hast du die Information über den Aufbau der Daten.
Um jetzt aus CL_ABAP_DATADESCR die Informationen zu einer Tabelle zu ermitteln, musst du nur Abfragen ob es sich tatsächlich um einen Tabellentyp handelt und dann die CL_ABAP_DATADESCR auf CL_ABAP_TABLEDESCR casten. Oder wenn du immer davon ausgehen kannst, dass hier Tabellen abgelegt werden kannst du gleich die CL_ABAP_TABLEDESCR verwenden.
Siehe dazu auch meinen Codeschnippsel.
lg ADT
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
2256
Views
Views
Oracle Datentypen in ABAP Datentypen umwandeln
von Steffi221185 » 07.08.2006 09:08 • Verfasst in ABAP® Core
von Steffi221185 » 07.08.2006 09:08 • Verfasst in ABAP® Core
3
Antw.
Antw.
1683
Views
Views
Beschreibung zu Klassenattributen etc. in adt
von whaslbeck » 15.12.2022 15:54 • Verfasst in ABAP Objects®
von whaslbeck » 15.12.2022 15:54 • Verfasst in ABAP Objects®
10
Antw.
Antw.
2657
Views
Views
3
Antw.
Antw.
2846
Views
Views
2
Antw.
Antw.
2543
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 10 Stunden von DeathAndPain 2 / 183
vor 10 Stunden von DeathAndPain 2 / 183
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 10 Stunden von DeathAndPain 2 / 183
vor 10 Stunden von DeathAndPain 2 / 183