Objektorientierung & ALVs
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo an all die ABAP-Experten,
ich programmiere jetzt seit 2 Jahren ABAP und ABAP OO und habe kürzlich das Buch ABAP Objects von Horst Keller gelesen.
Darin und auch in keinem Internetforum habe ich eine Antwort auf meine Frage gefunden. Noch etwas zu meinem Hintergrund, ich habe früher in .NET & C# entwickelt.
Aus .NET kenne ich Objektorientierung in der Form, dass ich an eine Liste eine Tabelle von Objekten per DataBinding geknüpft habe. Dort konnte ich angeben welche Membervariablen aus der Objekttabelle letztendlich auf der Liste angezeigt werden sollen. So hatte man in seiner Applikation eine Datentabelle, bestehend aus Business-Objekten, die jeweils eine Zeile der Tabelle abgebildet haben. Es war sogar möglich, für diese Tabelle eine Collection und keine simple Tabelle zu verwenden.
Meine Frage ist, wie löse ich das in ABAP optimalerweise. Ich habe ein ALV-Grid und möchte gerne in einer int. Tabelle die Referenzen auf meine Business Objekte halten. Dann habe ich alle Eigenschaften und Verhaltensweisen zur Verfügung, die mir das Business Object anbietet und kann ein Objekt einfach aus der int. Tabelle löschen. Nun habe ich das aber nicht hinbekommen und daher dann doch wieder auf die klassische Variante umgeschwenkt, dass ich die einzelnen Zeilen meines ALVs nicht sauber über Objekte abbilde, sondern eben als int. Tabelle einer simplen Struktur. Daher muss ich die Funktionen die eine einzelne Zeile haben soll wieder als statische Methoden abbilden oder ich erzeuge erst on demand ein Objekt, was ich aber alles unbefriedigend und nicht als saubere Lösung sehe.
Hat mir jemand einen Tipp oder ein Beispiel, wie ihr sowas schon mal sauber gelöst habt?
Vielen Danke im Voraus"
ich programmiere jetzt seit 2 Jahren ABAP und ABAP OO und habe kürzlich das Buch ABAP Objects von Horst Keller gelesen.
Darin und auch in keinem Internetforum habe ich eine Antwort auf meine Frage gefunden. Noch etwas zu meinem Hintergrund, ich habe früher in .NET & C# entwickelt.
Aus .NET kenne ich Objektorientierung in der Form, dass ich an eine Liste eine Tabelle von Objekten per DataBinding geknüpft habe. Dort konnte ich angeben welche Membervariablen aus der Objekttabelle letztendlich auf der Liste angezeigt werden sollen. So hatte man in seiner Applikation eine Datentabelle, bestehend aus Business-Objekten, die jeweils eine Zeile der Tabelle abgebildet haben. Es war sogar möglich, für diese Tabelle eine Collection und keine simple Tabelle zu verwenden.
Meine Frage ist, wie löse ich das in ABAP optimalerweise. Ich habe ein ALV-Grid und möchte gerne in einer int. Tabelle die Referenzen auf meine Business Objekte halten. Dann habe ich alle Eigenschaften und Verhaltensweisen zur Verfügung, die mir das Business Object anbietet und kann ein Objekt einfach aus der int. Tabelle löschen. Nun habe ich das aber nicht hinbekommen und daher dann doch wieder auf die klassische Variante umgeschwenkt, dass ich die einzelnen Zeilen meines ALVs nicht sauber über Objekte abbilde, sondern eben als int. Tabelle einer simplen Struktur. Daher muss ich die Funktionen die eine einzelne Zeile haben soll wieder als statische Methoden abbilden oder ich erzeuge erst on demand ein Objekt, was ich aber alles unbefriedigend und nicht als saubere Lösung sehe.
Hat mir jemand einen Tipp oder ein Beispiel, wie ihr sowas schon mal sauber gelöst habt?
Vielen Danke im Voraus"
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 / 4395 / 223 /
1182
)
»
Hi!
Du kannst deine Objektreferenz in einem Feld deiner Struktur die im ALV angezeigt wird ablegen. Im Feldkatalog musst du das Feld dann als TECH markieren, damit es nicht angezeigt wird. Somit hast du immer per Tabellenindex zugriff auf die Felder im ALV sowie auf das Objekt selbst. Leider funktioniert das ganze System nicht mit Objektattributen.
Was aber funktioniert ist der Zugriff auf Objektattribute in einem Dynpro (Table-Control). Hier kann man beim Feldnamen die -> bzw. => Syntax verwenden und so auf die Objekt- oder Klasseninhalte zugreifen.
Auch könnte ich mir eine Ableitung vom ALV-Grid vorstellen, die als Parameter eine Liste von Objekten übernimmt und deren Public-Attribute intern in die notwendige Struktur für die tatsächliche ALV-Anzeige umwandelt.
(RTTI und RTTC sei dank)
Kurz gesagt, auch aus C# oder Java bekannte Klassenkonzepte lassen sich in ABAP umsetzen... Es braucht nur jemanden der die Zeit hätte das zu machen...
lg ADT
Du kannst deine Objektreferenz in einem Feld deiner Struktur die im ALV angezeigt wird ablegen. Im Feldkatalog musst du das Feld dann als TECH markieren, damit es nicht angezeigt wird. Somit hast du immer per Tabellenindex zugriff auf die Felder im ALV sowie auf das Objekt selbst. Leider funktioniert das ganze System nicht mit Objektattributen.
Was aber funktioniert ist der Zugriff auf Objektattribute in einem Dynpro (Table-Control). Hier kann man beim Feldnamen die -> bzw. => Syntax verwenden und so auf die Objekt- oder Klasseninhalte zugreifen.
Auch könnte ich mir eine Ableitung vom ALV-Grid vorstellen, die als Parameter eine Liste von Objekten übernimmt und deren Public-Attribute intern in die notwendige Struktur für die tatsächliche ALV-Anzeige umwandelt.
(RTTI und RTTC sei dank)
Kurz gesagt, auch aus C# oder Java bekannte Klassenkonzepte lassen sich in ABAP umsetzen... Es braucht nur jemanden der die Zeit hätte das zu machen...
lg ADT
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
abapper
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 ralf.wenzel (Top Expert / 3923 / 200 /
280
)
»
Nur im ALV nicht oder generell in internen Tabellen nicht?a-dead-trousers hat geschrieben:Leider funktioniert das ganze System nicht mit Objektattributen.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
ALV!
Wie gesagt ist es in normalen Dynpros ja über Public-Attribute und -> bzw. => möglich. Da im ALV jedoch mit dem Feldkatalog bestehend aus Tabellennamen und Feldnamen gearbeitet wird, funktioniert das leider nicht.
In FIELDNAME müsste man theoretisch XXX->YYY reinschreiben können, aber das Feld ist dazu in vielen Fällen zu kurz.
Feldnamen 30 Zeichen + 2 Zeichen (->) + 30 Zeichen für das Attribut + evtl. noch 30 Zeichen für Interface + 1 Zeichen (~)
Um wirklich alle Eventualitäten abdecken zu können müsste das Feld im Feldkatalog also 93 Zeichen lang sein.
Im 132 Zeichen langen SCREEN-NAME ist das kein Problem.
lg ADT
Wie gesagt ist es in normalen Dynpros ja über Public-Attribute und -> bzw. => möglich. Da im ALV jedoch mit dem Feldkatalog bestehend aus Tabellennamen und Feldnamen gearbeitet wird, funktioniert das leider nicht.
In FIELDNAME müsste man theoretisch XXX->YYY reinschreiben können, aber das Feld ist dazu in vielen Fällen zu kurz.
Feldnamen 30 Zeichen + 2 Zeichen (->) + 30 Zeichen für das Attribut + evtl. noch 30 Zeichen für Interface + 1 Zeichen (~)
Um wirklich alle Eventualitäten abdecken zu können müsste das Feld im Feldkatalog also 93 Zeichen lang sein.
Im 132 Zeichen langen SCREEN-NAME ist das kein Problem.
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
a-dead-trousers hat geschrieben:Hi!
Du kannst deine Objektreferenz in einem Feld deiner Struktur die im ALV angezeigt wird ablegen. Im Feldkatalog musst du das Feld dann als TECH markieren, damit es nicht angezeigt wird. Somit hast du immer per Tabellenindex zugriff auf die Felder im ALV sowie auf das Objekt selbst. Leider funktioniert das ganze System nicht mit Objektattributen.
Was aber funktioniert ist der Zugriff auf Objektattribute in einem Dynpro (Table-Control). Hier kann man beim Feldnamen die -> bzw. => Syntax verwenden und so auf die Objekt- oder Klasseninhalte zugreifen.
Auch könnte ich mir eine Ableitung vom ALV-Grid vorstellen, die als Parameter eine Liste von Objekten übernimmt und deren Public-Attribute intern in die notwendige Struktur für die tatsächliche ALV-Anzeige umwandelt.
(RTTI und RTTC sei dank)
Kurz gesagt, auch aus C# oder Java bekannte Klassenkonzepte lassen sich in ABAP umsetzen... Es braucht nur jemanden der die Zeit hätte das zu machen...
lg ADT
Vielen Dank für die Antwort.
Ein guter Hinweis ist die Ableitung von der Standard-ALV-Klasse. Damit könnte man die Verhaltensweise implementieren, dass öffentliche Attribute automatisch als Anzeigefelder verwendet werden.
Die Variante, dass in der Struktur eine Objektreferenz abgelegt ist, läuft am OO-Konzept vorbei, da man die Daten die in einem Objekt gekapselt sein sollten, auch offen in der Struktur hält. Damit hat man zum Einen das Problem die redundanten Daten synchron zu halten und zum Anderen arbeitet man dann ja bequemerweise doch einfach wieder auf der Struktur und das Objekt wäre sinnlos.
Ich frage mich nur, hat noch niemand die ALV-Klasse so erweitert, dass eine oo-konforme Verhaltensweise möglich ist? Zumindest habe ich nirdends etwas dazu gefunden.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Zeit ist leider Geld! Im Umfeld von SAP/ABAP gilt das IMHO stärker als z.B. bei Java und Co. Für "Spielereien" ist oft einfach keine Zeit. Auch stammt der "typische" ABAP Entwickler eher noch aus einem R/3 System und hat gerade erst mit R/4 (ABAP-OO) begonnen.abapper hat geschrieben:Ich frage mich nur, hat noch niemand die ALV-Klasse so erweitert, dass eine oo-konforme Verhaltensweise möglich ist? Zumindest habe ich nirdends etwas dazu gefunden.
Und irgendwo soll sogar noch R/2 (da muss man noch Lochkarten stanzen
) im Einsatz sein.
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 ralf.wenzel (Top Expert / 3923 / 200 /
280
)
»
a-dead-trousers hat geschrieben:R/4 (ABAP-OO)
*prust*
Ich hatte heute echt einen Schlusstag, aber du hast ihn gerettet - YMMD
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Seite 1 von 1
Vergleichbare Themen
2
Antw.
Antw.
1724
Views
Views
1
Antw.
Antw.
1304
Views
Views
0
Antw.
Antw.
1493
Views
Views
3
Antw.
Antw.
2608
Views
Views
Einzelne Spalten eines ALVs eingabebereit
von SwordMaster » 06.10.2005 08:19 • Verfasst in Dialogprogrammierung
von SwordMaster » 06.10.2005 08:19 • Verfasst in Dialogprogrammierung
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 20 Stunden von DeathAndPain 4 / 837
vor 20 Stunden von DeathAndPain 4 / 837
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 20 Stunden von DeathAndPain 4 / 837
vor 20 Stunden von DeathAndPain 4 / 837