Dynamische Programmierung
a-dead-trousers hat geschrieben: ↑17.09.2022 09:15Das könnte am grundsätzlichen Aufbau deines Programms liegen (z.B. einer mehrfachen Instanzierung des ALV Grids im Zuge von PAI/PBO oder am Verhalten von Reports beim Rücksprung in den Selection-Screen das Programm neu zu starten)
Da müsstest du uns mehr Infos zum Programablauf liefern. Eventuell auch den Quellcode posten.
Code: Alles auswählen.
START-OF-SELECTION.
* create an object
DATA(r_final) = NEW zcl( ).
r_final->select_data( ).
r_final->display( ).
"-------------------------------------------------------------- Klassen
"Methode select_data.
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
SELECT .....
INTO TABLE @DATA(lt_result).
CREATE DATA mt_result LIKE lt_result. "mt_result als generisches attribut
ASSIGN mt_result->* TO <ft_result>.
<ft_result> = lt_result.
"Methode display
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>.
IF <ft_result> IS NOT INITIAL.
TRY.
CALL METHOD cl_salv_table=>factory
IMPORTING
r_salv_table = mo_alv_table
CHANGING
t_table = <ft_result>.
CATCH cx_salv_msg.
ENDTRY.
ENDIF.
DATA o_events TYPE REF TO cl_salv_events_table.
DATA: lo_obj TYPE REF TO zcL( ).
CREATE OBJECT lo_obj.
o_events = mo_alv_table->get_event( ).
SET HANDLER lo_obj->on_doubleclick FOR o_events.
mo_alv_table->display( ). "mo_alv_table als attribute type ref to cl_salv_table
"event methode ON_DOUBLECLICK
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>. " HIER FEHLEN mir die Daten um weiterzumachen
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Wir haben beim Blutspendedienst hunderte (!) ALVs gebaut, die mit REF TO DATA gearbeitet haben und die haben funktioniert. Als ich das bei meinem jetzigen Kunden machen wollte, hat das nicht geklappt mit genau dem gleichen Problem was der OP beschrieben hat. Ich meine auch, ich hätte das hier gepostet.
Insofern bin ich an einer Lösung interessiert.
Insofern bin ich an einer Lösung interessiert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Mal abgesehen von der furchtbaren ungarischen Notation, wird das so nicht funktionieren.
Je nach SAP Release brauchst du ein kein Feldsymbol mehr sondern kannst direkt mt_result->* = lt_result schreiben.
_ kennzeichnet ein Attribut einer Klasse. So ist es von Klassenvariablen leicht zu unterscheiden und kann gut als Vorlage für Getter und Setter genutzt werden.
Je nach SAP Release brauchst du ein kein Feldsymbol mehr sondern kannst direkt mt_result->* = lt_result schreiben.
_ kennzeichnet ein Attribut einer Klasse. So ist es von Klassenvariablen leicht zu unterscheiden und kann gut als Vorlage für Getter und Setter genutzt werden.
Code: Alles auswählen.
CLASS zcl_show_generic_alv DEFINITION
PUBLIC
CREATE PUBLIC .
PUBLIC SECTION.
METHODS show_alv .
METHODS get_article_data .
PROTECTED SECTION.
DATA _tab_generic_data TYPE REF TO data .
PRIVATE SECTION.
ENDCLASS.
CLASS zcl_show_generic_alv IMPLEMENTATION.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_SHOW_GENERIC_ALV->GET_ARTICLE_DATA
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD get_article_data.
SELECT *
FROM mara
INTO TABLE @DATA(tab_article).
CREATE DATA _tab_generic_data LIKE tab_article.
FIELD-SYMBOLS:
<any_data> TYPE any.
ASSIGN _tab_generic_data->* TO <any_data>.
<any_data> = tab_article .
ENDMETHOD.
* <SIGNATURE>---------------------------------------------------------------------------------------+
* | Instance Public Method ZCL_SHOW_GENERIC_ALV->SHOW_ALV
* +-------------------------------------------------------------------------------------------------+
* +--------------------------------------------------------------------------------------</SIGNATURE>
METHOD show_alv.
me->get_article_data( ).
IF _tab_generic_data IS NOT INITIAL.
DATA:
dat_tab TYPE REF TO data.
FIELD-SYMBOLS:
<tab_any> TYPE any.
ASSIGN _tab_generic_data->* TO <tab_any>.
cl_salv_table=>factory( IMPORTING
r_salv_table = DATA(obj_alv)
CHANGING
t_table = <tab_any>
).
obj_alv->display( ).
ENDIF.
ENDMETHOD.
ENDCLASS.
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Au, bitter. Hier ist einer gegen Ungarische Notation (was gut ist) aber für Setter und Getter (was grausig ist)?gtoXX hat geschrieben: ↑17.09.2022 12:41Mal abgesehen von der furchtbaren ungarischen Notation, wird das so nicht funktionieren.
Je nach SAP Release brauchst du ein kein Feldsymbol mehr sondern kannst direkt mt_result->* = lt_result schreiben.
_ kennzeichnet ein Attribut einer Klasse. So ist es von Klassenvariablen leicht zu unterscheiden und kann gut als Vorlage für Getter und Setter genutzt werden.
"_ kennzeichnet ein Attribut einer Klasse" -- wo steht das? So fangen bei mir die privaten Klassenkompenten an ;)
Ralf
PS: Zum Hintergrund: Methoden wie SET und GET zum isolierten Setzen und Lesen von Attributen taugen nichts, weil sie im Grunde nur das machen, was ein direkter Zugriff machen würde. Sinnvoller ist, das Setzen des Attributes mit dem Zustand zu verknüpfen, der erreicht werden soll. Also sowas wie "enable_feature_bla( input )", das erstens sprechend ist, zweitens weitere Dinge durchführen kann, die dazu notwendig sind und drittens den Wert verproben kann, der mitgegeben wird. Beim Lesen von Attributen genauso: Es bringt nix, ein "get_bla( )" aufzurufen, weil oft der gesamte Zustand des Objektes eine Rolle spielt und nicht nur ein isoliertes Attribut. Da wäre also ein "is_feature_bla_enabled( )" deutlich sinnvoller, weil es eben nicht nur das Attribut holt, sondern gleichzeitig prüfen kann, ob das Feature wirklich und auch korrekt und umfassend aktiv ist.
Zuletzt geändert von ralf.wenzel am 17.09.2022 12:54, insgesamt 1-mal geändert.
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
"event methode ON_DOUBLECLICK
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>. " HIER FEHLEN mir die Daten um weiterzumachen
Natürlich fehlen sie dir da. Du bist ja in einem ganz anderen Objekt. Nämlich diesem "lo_obj TYPE REF TO zcL( )." Woher soll das Objekt dein "mt_result->*" kennen ?
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>. " HIER FEHLEN mir die Daten um weiterzumachen
Natürlich fehlen sie dir da. Du bist ja in einem ganz anderen Objekt. Nämlich diesem "lo_obj TYPE REF TO zcL( )." Woher soll das Objekt dein "mt_result->*" kennen ?
"Code lügt nicht ^^"
Das ist zur Erklärung weil ich dies als Namenskonvention vorgegeben habe.ralf.wenzel hat geschrieben: ↑17.09.2022 12:47Au, bitter. Hier ist einer gegen Ungarische Notation (was gut ist) aber für Setter und Getter (was grausig ist)?gtoXX hat geschrieben: ↑17.09.2022 12:41Mal abgesehen von der furchtbaren ungarischen Notation, wird das so nicht funktionieren.
Je nach SAP Release brauchst du ein kein Feldsymbol mehr sondern kannst direkt mt_result->* = lt_result schreiben.
_ kennzeichnet ein Attribut einer Klasse. So ist es von Klassenvariablen leicht zu unterscheiden und kann gut als Vorlage für Getter und Setter genutzt werden.
"_ kennzeichnet ein Attribut einer Klasse" -- wo steht das? So fangen bei mir die privaten Klassenkompenten an ;)
Ralf
Das mit Setter Getter hast du missverstanden vermutlich. Du erstellst das Attribut mit _Attribut. Nimmst es in den Zwischenspeicher .. schreibst GET und fügst ein. Genauso eben bei seit. Ist nur so eine mögliche Arbeitsweise.
Die Sichtbarkeiten würde ich nie in Namenskonventionen bringen. Mal abgesehen davon das ich nirgends private verwende.
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Das Programm entstand nach deiner Vorgabe?
Wozu sollte man das tun?
Du verwendest nirgends private Komponenten? Das finde ich erstaunlich. Das hieße ja, deine Klassen bestehen nur aus PUBLIC.....
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Zu deinem Hintergrund : Dem kann ich so nicht zustimmen. Was ein Setter oder Getter macht ist bei weitem nicht isoliert. Es hängt ganz von deinem Objekttyp ab wie die Methodenbenamung ist. Ein DTO z.b. ist in der Regel zustandslos und nur ein reiner Datencontainer. Sprichst du aber zum Beispiel von einem Applikationsobjekt kann es natürlich Sinn machen eine Methode so zu benennen. Bzw. die Methode des Stateobjektes das die Applikation hält.ralf.wenzel hat geschrieben: ↑17.09.2022 12:47
PS: Zum Hintergrund: Methoden wie SET und GET zum isolierten Setzen und Lesen von Attributen taugen nichts, weil sie im Grunde nur das machen, was ein direkter Zugriff machen würde. Sinnvoller ist, das Setzen des Attributes mit dem Zustand zu verknüpfen, der erreicht werden soll. Also sowas wie "enable_feature_bla( input )", das erstens sprechend ist, zweitens weitere Dinge durchführen kann, die dazu notwendig sind und drittens den Wert verproben kann, der mitgegeben wird. Beim Lesen von Attributen genauso: Es bringt nix, ein "get_bla( )" aufzurufen, weil oft der gesamte Zustand des Objektes eine Rolle spielt und nicht nur ein isoliertes Attribut. Da wäre also ein "is_feature_bla_enabled( )" deutlich sinnvoller, weil es eben nicht nur das Attribut holt, sondern gleichzeitig prüfen kann, ob das Feature wirklich und auch korrekt und umfassend aktiv ist.
"Code lügt nicht ^^"
Zu deinem Hintergrund : Dem kann ich so nicht zustimmen. Was ein Setter oder Getter macht ist bei weitem nicht isoliert. Es hängt ganz von deinem Objekttyp ab wie die Methodenbenamung ist. Ein DTO z.b. ist in der Regel zustandslos und nur ein reiner Datencontainer. Sprichst du aber zum Beispiel von einem Applikationsobjekt kann es natürlich Sinn machen eine Methode so zu benennen. Bzw. die Methode des Stateobjektes das die Applikation hält.ralf.wenzel hat geschrieben: ↑17.09.2022 12:47
PS: Zum Hintergrund: Methoden wie SET und GET zum isolierten Setzen und Lesen von Attributen taugen nichts, weil sie im Grunde nur das machen, was ein direkter Zugriff machen würde. Sinnvoller ist, das Setzen des Attributes mit dem Zustand zu verknüpfen, der erreicht werden soll. Also sowas wie "enable_feature_bla( input )", das erstens sprechend ist, zweitens weitere Dinge durchführen kann, die dazu notwendig sind und drittens den Wert verproben kann, der mitgegeben wird. Beim Lesen von Attributen genauso: Es bringt nix, ein "get_bla( )" aufzurufen, weil oft der gesamte Zustand des Objektes eine Rolle spielt und nicht nur ein isoliertes Attribut. Da wäre also ein "is_feature_bla_enabled( )" deutlich sinnvoller, weil es eben nicht nur das Attribut holt, sondern gleichzeitig prüfen kann, ob das Feature wirklich und auch korrekt und umfassend aktiv ist.
"Code lügt nicht ^^"
Nein. Protected. Public ist absolut verboten weil es dafür nie einen vernünftigen Grund gibt.ralf.wenzel hat geschrieben: ↑17.09.2022 13:04
Du verwendest nirgends private Komponenten? Das finde ich erstaunlich. Das hieße ja, deine Klassen bestehen nur aus PUBLIC.....
Ralf
"Code lügt nicht ^^"
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Du hast recht, ich habe jetzt von "richtigen" Objekten gesprochen, die etwas tun. Aber selbst bei einem DTO kann es sein, dass ein Zustand von Attribut 1 davon abhängt, welchen Zustand ein anderes hat. Also im SAP-Sprech: Wenn ich eine Belegart für einen Referenzbeleg setzen will (im Originalbeleg), muss ich auch eine Belegnummer haben, sonst macht die Belegart keinen Sinn. Umgekehrt genauso. Das sollte auch ein DTO prüfen.gtoXX hat geschrieben: ↑17.09.2022 13:09Zu deinem Hintergrund : Dem kann ich so nicht zustimmen. Was ein Setter oder Getter macht ist bei weitem nicht isoliert. Es hängt ganz von deinem Objekttyp ab wie die Methodenbenamung ist. Ein DTO z.b. ist in der Regel zustandslos und nur ein reiner Datencontainer. Sprichst du aber zum Beispiel von einem Applikationsobjekt kann es natürlich Sinn machen eine Methode so zu benennen. Bzw. die Methode des Stateobjektes das die Applikation hält.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Beitrag
von ralf.wenzel (Top Expert / 3946 / 201 /
281
)
»
Bei Attributen gebe ich dir recht. Protected kann problematisch sein, weil die Sichtbarkeit zu weitreichend sein könnte. Aber das ist fallabhängig.
Ralf
Ralf Wenzel • Heuristika SAP-Development
25 Jahre SAP-Entwickler • 20 Jahre Freiberufler
Publikationen • Ungarische Notation • Xing
Danke, hätte ich mir denken können!gtoXX hat geschrieben: ↑17.09.2022 12:54"event methode ON_DOUBLECLICK
FIELD-SYMBOLS: <ft_result> TYPE STANDARD TABLE.
ASSIGN mt_result->* TO <ft_result>. " HIER FEHLEN mir die Daten um weiterzumachen
Natürlich fehlen sie dir da. Du bist ja in einem ganz anderen Objekt. Nämlich diesem "lo_obj TYPE REF TO zcL( )." Woher soll das Objekt dein "mt_result->*" kennen ?
Ja das kann man so machen. Es ist aber auch eine Frage wie das DTO eingesetzt wird, ob es selbst über seine Konsistenz entscheidet oder ob es z.b. über eine Factory erzeugt wird. Es kann ja durchaus sein, dass ich mein DTO in n Programmen einsetze, aber nicht immer alle Daten benötige und daher auch nicht in das DTO lade. Partner wäre so ein schönes Beispiel. Da gibt es n Daten die zum Partner gehören, aber im Programmkontext benötige ich nicht immer alle. Gerade bei Massenverarbeitung würde das den Speicherbedarf enorm aufblähen für nichts. Warum aber sollte ich mehrere DTOs bauen ? Mache ich mir aber ein zusammengesetztes DTO das alle Entitäten des Partners in DTOs hält, kann es Sinn machen, Prüfungen innerhalb jeden Einzel-DTOs zu implementieren, die die Konsistenz sicherstellen.ralf.wenzel hat geschrieben: ↑17.09.2022 13:12
Du hast recht, ich habe jetzt von "richtigen" Objekten gesprochen, die etwas tun. Aber selbst bei einem DTO kann es sein, dass ein Zustand von Attribut 1 davon abhängt, welchen Zustand ein anderes hat. Also im SAP-Sprech: Wenn ich eine Belegart für einen Referenzbeleg setzen will (im Originalbeleg), muss ich auch eine Belegnummer haben, sonst macht die Belegart keinen Sinn. Umgekehrt genauso. Das sollte auch ein DTO prüfen.
Ralf
"Code lügt nicht ^^"
Ja es ist ja immer alles etwas fallspezifisch. In dem Fall ist es eine Absicherung, falls für Kundenentwicklungen innerhalb der Produkte das nötig ist, wenn sie vererbt werden. Die Sichtbarkeit nachträglich zu ändern ohne sich dessen bewusst zu sein könnte auch Komplikationen mit sich bringen. In jedem Fall so oder so .. never public.ralf.wenzel hat geschrieben: ↑17.09.2022 13:20Bei Attributen gebe ich dir recht. Protected kann problematisch sein, weil die Sichtbarkeit zu weitreichend sein könnte. Aber das ist fallabhängig.
Ralf
"Code lügt nicht ^^"
Vergleichbare Themen
17
Antw.
Antw.
7739
Views
Views
2
Antw.
Antw.
1091
Views
Views
SAP Entwicklungssystem und RFC Programmierung
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
von sNud » 28.08.2021 13:36 • Verfasst in ABAP® für Anfänger
6
Antw.
Antw.
1549
Views
Views
Programmierung von SAP-Programm für API´s
von Bright4.5 » 12.12.2024 10:37 • Verfasst in ABAP® für Anfänger
von Bright4.5 » 12.12.2024 10:37 • Verfasst in ABAP® für Anfänger
1
Antw.
Antw.
2263
Views
Views
0
Antw.
Antw.
1610
Views
Views
Unicodevorgaben bei der Programmierung
von JürgenFFM » 07.11.2007 11:29 • Verfasst in Dialogprogrammierung
von JürgenFFM » 07.11.2007 11:29 • 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
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.