Interne Tabelle als ALV


Getting started ... Alles für einen gelungenen Start.

Moderatoren: Jan, Steff

Interne Tabelle als ALV

Beitragvon Lbyte » 14.11.2017, 15:52

Hallo zusammen,

ich schreibe momentan einen Report bei dem ich eine interne Tabelle aus mehreren vorhanden Tabellen erstellen, und die Ergebnisse dann als ALV ausgeben möchte.

Mich würde interessieren welcher FuBa sich hier eher eignet:

REUSE_ALV_GRID_DISPLAY

oder

DB2_DISPLAY_ITAB_TO_ALV_GRID.

Könnte mir jemand den Unterschied der beiden bzw die Vor,- und Nachteile erläutern.


Lieben Gruß
Lbyte
ForumUser
 
Beiträge: 11
Registriert: 12.10.2017, 12:29
Dank erhalten: 0 mal
Ich bin: Student/in

Sponsor

Alte ABAP-Entwicklerweisheit: Weißt du weder aus noch ein, baust du einen BADI ein

Re: Interne Tabelle als ALV

Beitragvon fr-g » 14.11.2017, 16:08

Deine Frage kann ich dir leider nicht beantworten... aber ich würde dir empfehlen, direkt die SALV-Klassen zu probieren, wenn nichts dagegen spricht:

Code: Alles auswählen
DATA: alv TYPE REF TO CL_SALV_TABLE,
      itab TYPE "dein itab-Typ

cl_salv_table=>factory(
   IMPORTING
      r_salv_table = alv
   CHANGING
      t_table      = itab ).
alv->display( ).


Einfacher kann man imo keinen ALV ausgeben ;)
fr-g
ForumUser
 
Beiträge: 19
Registriert: 26.05.2017, 15:25
Dank erhalten: 9 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon DeathAndPain » 14.11.2017, 17:45

Die Frage ist halt, wie bequem diese Klasse zu handhaben ist, wenn man mehr als gar nichts braucht, beispielsweise einen vernünftigen (d.h. nicht blind auf das DDIC vertrauenden) Feldkatalog. Gehen wird es sicherlich, aber OO ist oft sehr umständlich.

Der Klassiker ist der REUSE_ALV_GRID_DISPLAY. Den anderen Baustein kenne ich nicht, was mich zu der Vermutung bringt, dass es sich dabei um einen Exoten handelt, der wahrscheinlich keine so gute Wahl ist.
DeathAndPain
Specialist
 
Beiträge: 266
Registriert: 05.05.2006, 10:14
Dank erhalten: 65 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon fr-g » 14.11.2017, 18:39

Was ist denn am FuBa-ALV-Feldkatalog vernünftiger? Ist eine ernst gemeinte Frage. Ich kenn mich eigentlich nur mit dem OO-ALV aus und bin da bis jetzt kaum an Grenzen gestoßen. Ich kann ja durchaus noch einige Anpassungen am ALV vornehmen und muss mich nicht mit den DDIC-Werten zufrieden geben. Und der Aufruf der zwei drei Methoden macht mein Programm ja noch nicht komplett objektorientiert.
Was wäre ein Anwendungsbeispiel, dass mit REUSE_ALV_GRID_DISPLAY besser geht? Würde mich wirklich interessieren :)

Für diese Nachricht hat fr-g einen Dank bekommen :
ST22
fr-g
ForumUser
 
Beiträge: 19
Registriert: 26.05.2017, 15:25
Dank erhalten: 9 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon DeathAndPain » 15.11.2017, 11:26

Na ja, wenn ich ein ALV nutze, dann sieht mein Hauptprogramm in etwa so aus:

Code: Alles auswählen
DATA: ALV_FIELDCAT   TYPE SLIS_T_FIELDCAT_ALV WITH HEADER LINE,
      ALV_LAYOUT     TYPE SLIS_LAYOUT_ALV,
      ALV_VARIANT    LIKE DISVARIANT.

PERFORM ALV_LAYOUT_ERZEUGEN.
PERFORM ALV_AUSGEBEN. " interne Tabelle mit ALV-Daten heißt in diesem Beispiel M
   
*&---------------------------------------------------------------------*
*&      Form  ALV_LAYOUT_ERZEUGEN
*&---------------------------------------------------------------------*
FORM ALV_LAYOUT_ERZEUGEN.
  CONSTANTS X VALUE 'X'.
  REFRESH ALV_FIELDCAT.
  ALV_LAYOUT-COLWIDTH_OPTIMIZE = SPACE.
*  ALV_LAYOUT-INFO_FIELDNAME = 'LINECOLOR'. " Feld für Zeilenfarbe
  ALV_LAYOUT-ZEBRA = X.
  ALV_LAYOUT-CELL_MERGE = X.

  ALV_VARIANT-REPORT = SY-REPID.
  ALV_VARIANT-HANDLE = 'HAUPT'.

  PERFORM NONDDIC_FIELDCATENTRY USING 8 'N' 'PERNR' 'Persnr' 'Personalnr' 'Personalnummer' SPACE SPACE.
  PERFORM NONDDIC_FIELDCATENTRY USING ... all die anderen Spalten mit Komponentenbezeichnung, Kurztext, mittellangem Text und Langtext sowie Flag für Groß/Kleinschreibung und NO_OUT
ENDFORM.                    " ALV_LAYOUT_ERZEUGEN

*&---------------------------------------------------------------------*
*&      Form  NONDDIC_FIELDCATENTRY
*&---------------------------------------------------------------------*
FORM NONDDIC_FIELDCATENTRY  USING OUTPUTLEN INTTYPE FIELDNAME SELTEXT_S SELTEXT_M SELTEXT_L LOWERCASE NO_OUT.
  ALV_FIELDCAT-OUTPUTLEN = OUTPUTLEN.
  ALV_FIELDCAT-INTTYPE = INTTYPE.
  ALV_FIELDCAT-FIELDNAME = FIELDNAME.
  ALV_FIELDCAT-SELTEXT_S = SELTEXT_S.
  ALV_FIELDCAT-SELTEXT_M = SELTEXT_M.
  ALV_FIELDCAT-SELTEXT_L = SELTEXT_L.
  ALV_FIELDCAT-LOWERCASE = LOWERCASE.
  ALV_FIELDCAT-NO_OUT = NO_OUT.
  APPEND ALV_FIELDCAT.
ENDFORM.                    " NONDDIC_FIELDCATENTRY

*&---------------------------------------------------------------------*
*&      Form  ALV_AUSGEBEN
*&---------------------------------------------------------------------*
FORM ALV_AUSGEBEN.
  DATA REPID LIKE SY-REPID.
  MOVE SY-REPID TO REPID.

  CALL FUNCTION 'REUSE_ALV_GRID_DISPLAY'
    EXPORTING
      I_CALLBACK_PROGRAM      = REPID
     I_CALLBACK_PF_STATUS_SET = 'SET_PF_STATUS'
      I_CALLBACK_USER_COMMAND = 'USER_COMMAND'
      IS_LAYOUT               = ALV_LAYOUT
      IT_FIELDCAT             = ALV_FIELDCAT{} " sind eckige Klammern, aber die mutieren optisch im Forum
      I_SAVE                  = 'U'
      IS_VARIANT              = ALV_VARIANT
    TABLES
      T_OUTTAB                = M.
ENDFORM.                    " ALV_AUSGEBEN

*&---------------------------------------------------------------------*
*&      Form  SET_PF_STATUS
*&---------------------------------------------------------------------*
FORM SET_PF_STATUS USING RT_EXTAB TYPE SLIS_T_EXTAB.
  SET PF-STATUS 'ALV'.
ENDFORM.                    " SET_PF_STATUS

*&---------------------------------------------------------------------*
*&      Form  USER_COMMAND
*&---------------------------------------------------------------------*
FORM USER_COMMAND USING I_UCOMM I_SELFIELD TYPE SLIS_SELFIELD.
  DATA: DOKUOBJEKT TYPE DOKHL-OBJECT.
  CASE I_UCOMM.
    WHEN 'USE'. " Programmdokumentation anzeigen
      DOKUOBJEKT = SY-REPID.
      CALL FUNCTION 'DOCU_CALL'
        EXPORTING
          DISPL      = 'X'
          DISPL_MODE = '2'
          ID         = 'RE'
          LANGU      = 'D'
          OBJECT     = DOKUOBJEKT.
    WHEN '&IC1'. " Doppelklick auf ALV-Zeile
      CLEAR M.
      READ TABLE M INDEX I_SELFIELD-TABINDEX.
      CHECK NOT M-PERNR IS INITIAL.
      " Bei Doppelklick in die PA20 abspringen, sofern entsprechende Berechtigung vorliegt
      AUTHORITY-CHECK OBJECT 'S_TCODE' ID 'TCD' FIELD 'PA20'.
      CHECK SY-SUBRC = 0.
      CALL FUNCTION 'HR_CHECK_AUTHORITY_PERNR'
        EXPORTING  PERNR = M-PERNR
        EXCEPTIONS NO_AUTHORIZATION_FOR_PERNR = 1.
      IF SY-SUBRC <> 0.
        MESSAGE TEXT-NOA TYPE 'S' DISPLAY LIKE 'E'.
        EXIT.
      ENDIF.
      SET PARAMETER ID 'PER' FIELD M-PERNR.
      CALL TRANSACTION 'PA20' AND SKIP FIRST SCREEN.
  ENDCASE.
ENDFORM.                    " USER_COMMAND


Das ist bedeutend länger als das, was Du geschrieben hast, aber dafür gebe ich bei jeder Spalte zu meinem Programm passende Spaltenüberschriften an, statt darauf zu vertrauen, dass das DDIC schon was Gutes bieten wird (häufig hat man ja auch programmspezifische Spalten, die es im DDIC gar nicht gibt). Ich kann die Felder nach Maß attributieren, etwa per 'X' beim NO_OUT-Parameter Spalten hinzufügen, die man meist nicht braucht und die daher nur dem Spaltenvorrat hinzugefügt werden, so dass der Anwender sie sich bei Bedarf einblenden kann. Mit der Variablen ALV_VARIANT unterstütze ich Layoutvarianten nebst Handle (letzteres ist wichtig, wenn es im Programm mehrere ALVs gibt, damit das System unterscheiden kann, welche Layoutvariante des Reports zu welchem ALV gehört). Ich unterstütze einen eigenen, per SE43 (oder für diejenigen, die pauschal mit der schnarchlahmen SE80 arbeiten, auch damit) anlegbaren Oberflächenstatus, bei dem ich die Standard-ALV-Schaltflächen um eigene erweitere oder - fast noch wichtiger - sinnlose Standardschaltflächen, die man so gut wie bei keinem ALV braucht und die das Ganze nur unübersichtlich machen (ABC-Analyse...), ausblende. Ich reagiere auf Doppelklick auf eine Zeile (im Beispiel damit, dass ich in die Anzeige der gedoppelklickten Personalnummer abspringe). Ich biete das aus Selektionsbildern online dokumentierter Reports bekannte blaue i-Symbol mit Absprung in die Online-Dokumentation des Reports. In dem Abschnitt kann ich auch auf eigene Schaltflächen reagieren.

So ist das für mich ein ALV, das man in einem produktiven Report einem Anwender anbieten kann.

Die OO-basierten Mechaniken können das auch alles; SAP entfernt da keine Funktionalitäten. Insofern bin ich sicher, dass das mit Deiner Methode auch irgendwie gehen wird. Aber nach meiner Erfahrung muss man da ohne Ende Overhead programmieren, Parameter in irgendwelchen Objektattributen und Containerobjekten verstecken usw. Da ich mich mit Deiner Methode nicht auskenne, spiele ich den Ball mal zurück: Wenn Du all das oben von mir Aufgezählte bieten wolltest, wie würde Dein Code dann aussehen? Bin ehrlich neugierig, ob der dann immer noch kurz und übersichtlich ist oder gewaltig anschwillt und/oder schwer nachvollziehbar ist.

Für diese Nachricht hat DeathAndPain einen Dank bekommen :
fr-g
DeathAndPain
Specialist
 
Beiträge: 266
Registriert: 05.05.2006, 10:14
Dank erhalten: 65 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon 4byte » 15.11.2017, 13:25

Hallo zusammen,

um wieder auf die Frage von Lbyte zurück zu kommen:

Beide Möglichkeiten von fr-g und DeathAndPain sind zielführend :up: :up: Welche von beiden du jetzt nutzt bleibt meiner Meinung nach Geschmackssache. Ich verwende oft und gerne die OO Lösung mit CL_SALV_TABLE :D :)
Es gibt 10 Menschen die binär verstehen :)
4byte
ForumUser
 
Beiträge: 1
Registriert: 24.10.2017, 09:16
Dank erhalten: 0 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon black_adept » 15.11.2017, 13:33

Ein paar Anmerkdungen zu Death&Pains Codeschnipseln
  • Globale Variablen sollten nicht verwendet werden
  • Kopfzeilen schon mal gar nicht
  • Früher habe ich auch die REUSE...-FuBas verwendet. Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC. Funktionell unterscheidet sich das nicht - aber der LVC-FuBa verwendet die Strukturen, die auch die Klasse CL_GUI_ALV_GRID verwendet, so dass man sich nicht merken muss ob das Feld nun "COLWIDTH_OPTIMIZE" ( Reuse) oder "CWIDTH_OPT"( cl_gui_alv_grid ) heißt. Außerdem sind die zugehörigen LVC-Strukturen im DDIC abgelegt und nicht in einer Typgruppe wie bei der REUSE-Version
  • Manuelles Aufbauen eines Feldkatalogs? Ich dachte Programmierer sind faul. Davon abgesehen muss man in dem Fall auch noch die ganzen Übersetzungen mitliefern ( es sei denn man programmiert für eine rein deutsche Firma - soll es ja auch noch geben ). Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt. Coding hierzu ist nicht groß anders als bei D&P, aber bei Strukturerweiterungen gibt es die gute Chance, dass man hier nichts mehr anpassen muss
    Code: Alles auswählen
     Feldkatalog lt_fcat erstellen lassen ( z.B. mit LVC_FIELDCATALOG_MERGE oder andere Themen hier im Forum
    loop at lt_fcat assigning ...
    case columname.
    when 'FELDXYZ'.  Besondere Eigenschaften hier setzen
    when 'WEITERES_FELD'. Andere Eigenschaften setzen
    endcase.
    endloop.

Und noch 2 Anmerkungen zu fr-g.
  • Meines Wissen war die von SAP im Laufe der Jahre empfohlene ALV-Listdarstellung folgende:
    • ganz alt: Die REUSE-Bausteine
    • die Klasse cl_gui_alv_grid ( Objektorientiert )
    • die SALV-Klasse, weil die noch viel mehr auf Objektorientierung setzt
    • aktuell wieder: Die Klasse cl_gui_alv_grid
  • Du fragtest nach den Grenzen des OO-Alv (SALV). Da gibt es einiges. Direkt fällt mir ein, was bei der cl_gui_alv_grid unterstützt wird, beim SALV hingegen nicht mit Bordmitteln sondern nur über Tricksereien, die dann doch beim cl_gui_alv_grid landen:
    • Editierbarkeit von Zellen
    • Kontextmenüs
    • Drag & Drop
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
fr-g
black_adept
Top Expert
 
Beiträge: 2710
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 388 mal
Ich bin: Freiberufler/in

Re: Interne Tabelle als ALV

Beitragvon Romaniac » 15.11.2017, 16:02

Ich nutze immer wenn ich nicht editieren muss den SALV:

Code: Alles auswählen
DATA:
  t_table      TYPE TABLE OF lips,
  r_salv_colsl TYPE REF TO cl_salv_columns_list,
  r_salv_sorts TYPE REF TO cl_salv_sorts.

CALL METHOD cl_salv_table=>factory
  IMPORTING
    r_salv_table = DATA(r_salv)
  CHANGING
    t_table      = t_table.

r_salv->get_columns( )->set_optimize( abap_true ).

* Icon oder Text in der Mitte der Zelle
r_salv_colsl->get_column( 'STATUS_ACC' )->set_alignment( if_salv_c_alignment=>centered ).

* Sort
r_salv_sorts = r_salv->get_sorts( ).
r_salv_sorts->add_sort( columnname = 'AWREF'
                        position = 1 ).
r_salv_sorts->add_sort( columnname = 'GLX_DOCNR'
                        position = 2 ).

PERFORM salv_rename_col USING r_salv_colsl:
  'MESSAGE'       text-mes,
  'VBELN'         text-bel.

r_salv_colsl->set_color_column( 'T_COLOR' ).
r_salv_colsl->set_cell_type_column( 'T_STYLE' ).
r_salv->display( ).


FORM salv_rename_col
  USING iref_alv_cols  TYPE REF TO cl_salv_columns_list
        iv_fieldname   TYPE fieldname
        iv_text        TYPE itex132.

  DATA:
    lref_alv_col TYPE REF TO cl_salv_column_table,
    lref_error   TYPE REF TO cx_root,
    lv_text_s    TYPE scrtext_s,
    lv_text_m    TYPE scrtext_m,
    lv_text_l    TYPE scrtext_l.

  lv_text_l =
  lv_text_m =
  lv_text_s = iv_text.
  TRY.
      lref_alv_col ?= iref_alv_cols->get_column( iv_fieldname ).
    CATCH cx_salv_not_found INTO lref_error.
  ENDTRY.

  IF NOT lref_error IS BOUND.
    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.
  ENDIF.
ENDFORM.


und viele Funktionen mehr die ich ausgelagert habe in Forms(hatte noch keine Zeit um Mehtoden draus zu machen)

Gruß Wolfgang
Geht nicht gibts nicht
Romaniac
ForumUser
 
Beiträge: 52
Registriert: 20.03.2017, 10:31
Wohnort: Augsburg
Dank erhalten: 7 mal
Ich bin: Freiberufler/in

Re: Interne Tabelle als ALV

Beitragvon DeathAndPain » 15.11.2017, 16:40

Globale Variablen sollten nicht verwendet werden

In meinen Augen geht GMV (gesunder Menschenverstand) vor starren Regeln. In echter Logik benutze ich keine globalen Variablen. Ein ALV ist jedoch vergleichbar etwa einem Dynpro (in dem ja von der SAP vorgegebenermaßen auch alles global ist). Von daher sehe ich es entspannt, wenn meine ALV-Ausgabetabelle und deren Layout global ist.

Ansonsten sind bei mir auch Puffertabellen global. Wenn ich auf bestimmte Datensätze einer Tabelle so häufig zugreifen muss, dass ich mir mit einer programmspezifischen Puffertabelle tausende von SELECTs sparen kann (und die Arbeitsspeicherbelastung im Rahmen ist), dann kopiere ich die benötigten Felder mit einem dicken SELECT in eine passende, sortierte Puffertabelle. Die darf dann von überall im Programm anstelle von SELECTs genutzt werden. Auch hier ist die Verständlichkeit gegeben, denn die Tabelle heißt BUFFER_irgendwasSprechendes und wird genau einmal gefüllt, nämlich zum Programmstart. Die dann mit Parametern überall mit durchzureichen, möglicherweise gar über mehrere Etagen verschachtelter Unterprogramme, von denen nur das unterste solch SELECT-Ersatz nutzen möchte, fände ich affig.

Kopfzeilen schon mal gar nicht

Bekanntlich bin ich ein großer Fan von Kopfzeilen und halte die Empfehlung, sie nicht mehr zu nutzen, für eine willkürliche Modeerscheinung. IMHO ist für jeden, der ABAP kann, aus dem Kontext auf einen Blick ersichtlich, ob er eine Kopfzeile oder den Tabellenrumpf vor sich hat, bzw. bei Tabellenrümpfen gebe ich immer explizit [] an (und nutze REFRESH statt CLEAR). Die Anforderungen an das geistige Abstraktionsvermögen, die durch Feldsymbole, funktionale Methoden und Variablenreferenzen, am besten noch in einem Ausdruck geschachtelt, an den Programmierer gestellt werden, sind um Größenordnungen größer als die Arbeit mit Kopfzeilen.

Allerdings geht die Nutzung von Kopfzeilen bei mir in letzter Zeit auch deutlich zurück, weil Feldsymbole und VALUE/CONV sie zunehmend unnötig machen. Wenn ich eine Zeile vor dem APPEND nicht mehr in einer Workarea aufbauen muss, brauche ich keine Kopfzeile. Wenn ich mir per LOOP AT variable ASSIGNING FIELD-SYMBOL(<variable>) en passant eine passende Workarea mit sprechendem Namen beschaffen kann, dann ist das wunderbar, und ich bin nur etwas unglücklich darüber, dass die Winkelklammern um den Variablennamen sich so blöd tippen. Der einst von der SAP bei TABLES gewählte Ansatz, eine zweite Workarea per Stern vor dem Tabellennamen bereitzustellen, erscheint mir bedeutend programmiererfreundlicher und zugleich hervorragend lesbar. Wenn bei jeder Deklaration einer internen Tabelle TABELLENNAME implizit eine Workarea *TABELLENNAME entstehen würde, wäre ich superzufrieden (der eine Stern wäre mir egal), und den Gegnern der Kopfzeile wäre der Wind aus den Segeln genommen. Aber eine zusätzliche Deklarationszeile DATA WA_TABELLENNAME LIKE LINE OF TABELLENNAME ist einfach Codemüll, und der Vorsatz WA_ tippt sich obendrein umständlich und vermindert nach meiner Überzeugung ob seiner Länge die Lesbarkeit des Codes.

Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC.

Ich kann mich erinnern, den auch schon ein paarmal benutzt zu haben, weil er Sachen kann, die der REUSE nicht beherrscht. Das waren aber exotische Sachen, die man nur bei ganz wenigen ALVs braucht, und ich meine mich zu erinnern, dass beim LVC irgendwas umständlicher war. Das kann ich aber nicht belegen, und vielleicht täusche ich mich da auch. Ich bin halt beim REUSE geblieben, weil er perfekt ausreicht und ich halt ein neues ALV schnell per Copy&Paste aus einem Altprogramm hinbekomme (im Prinzip der Code, den ich oben gepostet habe).

Manuelles Aufbauen eines Feldkatalogs? Ich dachte Programmierer sind faul.

Das sind sie; deswegen dokumentiert ja auch niemand. Das ist für mich aber kein Maßstab.

Davon abgesehen muss man in dem Fall auch noch die ganzen Übersetzungen mitliefern ( es sei denn man programmiert für eine rein deutsche Firma - soll es ja auch noch geben ).

Bei einer Firma, in der es komplett international SAPGui-User gibt, die sich in ihrer jeweiligen Landessprache anmelden, hast Du recht. Meine Firma ist auch international tätig, aber da ist die (nicht von mir stammende) Ansage, dass alles, was nicht deutsch ist, mit englisch arbeitet. Ich muss also den Feldkatalog neben deutsch per CASE SY-LANGU auch noch auf englisch bereitstellen, wenn es ein Programm ist, von dem ich nicht genau weiß, dass es nur in Deutschland genutzt werden wird, und dann ist das gut.

Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt.

Habe ich mir auch schon überlegt, bin dann aber darüber gestolpert, dass ich von 20 Feldern doch 17 umdefinieren musste, und dann lohnt der Fax nicht. Das hängt auch damit zusammen, dass die Bedeutung vieler Felder kontextabhängig ist. Wenn ich beispielsweise eine Liste von Planstellen ausgebe, dann habe ich darin zwei Felder vom Typ PERNR. Die DDIC-Beschreibung "Personalnummer" nützt mir da aber nichts, schon gar nicht doppelt in derselben Liste, sondern die eine Spalte soll mit "Planstelleninhaber" und die andere mit "Führungskraft" überschrieben werden. Bei Feldern, deren Wert ich erst im Programm zusammenbaue (etwa Berechnungsergebnisse), lässt das DDIC mich sowieso im Stich.

Insofern habe ich das mit der DDIC-Unterstützung vor Jahren mal versucht und bin schnell davon abgekommen. Ja, der Aufbau des Feldkatalogs ist eine Fleißarbeit und ja, ich hasse sie, aber wenn ich mit dem Ergebnis zufrieden sein will, gibt es keinen anderen Weg.

Meines Wissen war die von SAP im Laufe der Jahre empfohlene ALV-Listdarstellung folgende:

ganz alt: Die REUSE-Bausteine
die Klasse cl_gui_alv_grid ( Objektorientiert )
die SALV-Klasse, weil die noch viel mehr auf Objektorientierung setzt
aktuell wieder: Die Klasse cl_gui_alv_grid

Schön, dass sogar die SAP mal gemerkt hat, dass Objektorientierung nur um der Objektorientierung willen auch keine Punkte bringt.
DeathAndPain
Specialist
 
Beiträge: 266
Registriert: 05.05.2006, 10:14
Dank erhalten: 65 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon DeathAndPain » 15.11.2017, 16:47

Romaniac hat geschrieben:
Code: Alles auswählen
    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.

Dieser Ausschnitt ist ein schönes Beispiel, weshalb ich den Kram nicht mag. Beim Aufbau des Feldkatalogs habe ich eine Struktur, der ich halt die benötigten Werte zuweise und fertig. Hier muss man für jeden einzelnen Wert extra eine Methode aufrufen und das ganze noch über einen TRY-ENDTRY-CATCH-Block absichern, damit einem der Mist nicht dumpen kann. Das finde ich nicht modern, sondern krank.
DeathAndPain
Specialist
 
Beiträge: 266
Registriert: 05.05.2006, 10:14
Dank erhalten: 65 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon black_adept » 16.11.2017, 01:53

DeathAndPain hat geschrieben:[...] Ich muss also den Feldkatalog neben deutsch per CASE SY-LANGU auch noch auf englisch bereitstellen,

CASE SY-LANGU und nicht Textsymbole? SLIN wird nie dein Freund werden....
DeathAndPain hat geschrieben:
Vorteilhafter erscheint mir das Erstellen eines Feldkatalogs (kann gekapselt und wiederverwendet werden ) und dann manuelle Anpassungen für diejenigen Spalten, die nicht so bleiben sollen wie das System das vorschlägt.

Habe ich mir auch schon überlegt, bin dann aber darüber gestolpert, dass ich von 20 Feldern doch 17 umdefinieren musste, und dann lohnt der Fax nicht. Das hängt auch damit zusammen, dass die Bedeutung vieler Felder kontextabhängig ist. Wenn ich beispielsweise eine Liste von Planstellen ausgebe, dann habe ich darin zwei Felder vom Typ PERNR. Die DDIC-Beschreibung "Personalnummer" nützt mir da aber nichts, schon gar nicht doppelt in derselben Liste, sondern die eine Spalte soll mit "Planstelleninhaber" und die andere mit "Führungskraft" überschrieben werden. Bei Feldern, deren Wert ich erst im Programm zusammenbaue (etwa Berechnungsergebnisse), lässt das DDIC mich sowieso im Stich.

Insofern habe ich das mit der DDIC-Unterstützung vor Jahren mal versucht und bin schnell davon abgekommen. Ja, der Aufbau des Feldkatalogs ist eine Fleißarbeit und ja, ich hasse sie, aber wenn ich mit dem Ergebnis zufrieden sein will, gibt es keinen anderen Weg.

Das habe ich noch nie gehört. Ich kann mir ja vorstellen, dass eine Spalte mal Planstelleninhaber und mal Führungskraft heißen soll. Und wenn das nur in einem einzigen Report vorkommt kann man ja auch so vorgehen wie du. Aber ich kanngar nicht glauben, dass es nicht noch zig andere Reports gibt, die diese Bezeichnungen auch noch brauchen könnten. Wenn du schon den ganzen Aufwand treibst - warum dann nicht im DDIC Datenelemente anlegen mit den richtigen Bezeichnungen und damit mit Wiederverwendungsmöglichkeit?
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de

Für diese Nachricht hat black_adept einen Dank bekommen :
ralf.wenzel
black_adept
Top Expert
 
Beiträge: 2710
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 388 mal
Ich bin: Freiberufler/in

Re: Interne Tabelle als ALV

Beitragvon abuma » 16.11.2017, 09:46

huhu,

also ich persönlich finde salv schon sehr praktisch, gerade auch mit der Feldliste die man nicht selber mühsam aufbauen muss.
Der größte Teil wird somit mit sprechenden Texten, die von der SAP schon in versch. Sprachen gepflegt wurden, befüllt.
Bei einzelnen Spalten die ich anders benennen möchte, mache ich es so wie Romaniac:
Romaniac hat geschrieben:
CODE: ALLES AUSWÄHLEN
TRY.
lref_alv_col->set_long_text( lv_text_l ).
lref_alv_col->set_medium_text( lv_text_m ).
lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
" dann wird nur der Langtext spaltenoptimiert angezeigt
CATCH cx_salv_not_found.
ENDTRY.

Diesen Block kann man ja auch in eine weitere Methode auslagern, so geht das denke ich viel schneller wie das befüllen eines kompletten Feldkatalogs und hat eben den Vorteil der bereits Übersetzten Texte.

Aber natürlich kommt es auch immer auf die Anforderung an, welches ALV man verwenden sollte.
Gerade bei Anforderungen mit Editiermöglichkeit nutze ich die objektorientierte Variante nicht.

Liebe Grüße
abuma
abuma
ForumUser
 
Beiträge: 46
Registriert: 17.08.2016, 11:14
Dank erhalten: 5 mal
Ich bin: Entwickler/in

Re: Interne Tabelle als ALV

Beitragvon black_adept » 16.11.2017, 10:49

abuma hat geschrieben:also ich persönlich finde salv schon sehr praktisch, gerade auch mit der Feldliste die man nicht selber mühsam aufbauen muss.

Das ist aber kein Alleinstellungsmerkmal des SALV, sondern den automatisierten Aufbau der Feldliste gibt es auch für alle anderen ALV-Versionen. Evtl. muss man einen Fuba/Methode dazu aufrufen, aber häufig genug kann man auf das DDIC referenzieren und alles klappt auch hier automatisch.
live long and prosper
Stefan Schmöcker

email: stefan@schmoecker.de
black_adept
Top Expert
 
Beiträge: 2710
Registriert: 08.01.2003, 13:33
Wohnort: Lehrte ( bei Hannover )
Dank erhalten: 388 mal
Ich bin: Freiberufler/in

Re: Interne Tabelle als ALV

Beitragvon ralf.wenzel » 17.11.2017, 09:13

DeathAndPain hat geschrieben:
Globale Variablen sollten nicht verwendet werden

In meinen Augen geht GMV (gesunder Menschenverstand) vor starren Regeln. In echter Logik benutze ich keine globalen Variablen. Ein ALV ist jedoch vergleichbar etwa einem Dynpro.


Nein. Ein Dynpro funktioniert nach einem ganz anderes Prinzip als ein ALV, was man schon daran erkennt, dass ein ALV ein Dynpro braucht.

DeathAndPain hat geschrieben:Ansonsten sind bei mir auch Puffertabellen global.


Bei dir vielleicht ;) Ich verwende Klassenattribute (und ja, das ist etwas ganz anderes).

DeathAndPain hat geschrieben:
Kopfzeilen schon mal gar nicht

Bekanntlich bin ich ein großer Fan von Kopfzeilen und halte die Empfehlung, sie nicht mehr zu nutzen, für eine willkürliche Modeerscheinung.


Es ist eher eine willkürliche ABAP-Erscheinung, dass man einen Variablennamen für unterschiedliche Variablen verwendet und man nur deshalb REFRESH erfindet, obwohl ein CLEAR reicht. Eine Tabelle ist für mich eine Variable und die lösche ich mit CLEAR.

DeathAndPain hat geschrieben:LOOP AT variable ASSIGNING FIELD-SYMBOL(<variable>) en passant eine passende Workarea mit sprechendem Namen beschaffen kann, dann ist das wunderbar, und ich bin nur etwas unglücklich darüber, dass die Winkelklammern um den Variablennamen sich so blöd tippen.


Lösung: LOOP AT variable INTO DATA(variable). Ich aber bevorzuge Feldsymbole, weil das schön knallt, wenn es nicht zugewiesen ist, statt einfach nur "leer" zu sein (bei einem LOOP nicht relevant, bei einem READ schon).

DeathAndPain hat geschrieben:Der einst von der SAP bei TABLES gewählte Ansatz, eine zweite Workarea per Stern vor dem Tabellennamen bereitzustellen, erscheint mir bedeutend programmiererfreundlicher und zugleich hervorragend lesbar.


Das und implizite Kopfzeilen sind Dinge, deren Verständnis denen sehr schwer fällt, die aus anderen Programmiersprachen kommen. Das spricht sicher für sich.

Heutzutage nehme ich statt des REUSE_ALV_GRID_DISPLAY lieber den REUSE_ALV_GRID_DISPLAY_LVC.


Ich nutze im Allgemeinen die SALV-Klasse. Das ist am einfachsten zu skalieren, vom Einfachstaufruf (der wirklich sehr einfach ist) bis hin zu sehr komplexem Gedöns.



Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2636
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 116 mal
Ich bin: Freiberufler/in

Re: Interne Tabelle als ALV

Beitragvon ralf.wenzel » 17.11.2017, 09:17

DeathAndPain hat geschrieben:
Romaniac hat geschrieben:
Code: Alles auswählen
    TRY.
        lref_alv_col->set_long_text( lv_text_l ).
        lref_alv_col->set_medium_text( lv_text_m ).
        lref_alv_col->set_short_text( lv_text_s ). " --> wenn text( '' ) gesetzt wird und nur langtext mit Spaltenoptimierung
        " dann wird nur der Langtext spaltenoptimiert angezeigt
      CATCH cx_salv_not_found.
    ENDTRY.

Dieser Ausschnitt ist ein schönes Beispiel, weshalb ich den Kram nicht mag. Beim Aufbau des Feldkatalogs habe ich eine Struktur, der ich halt die benötigten Werte zuweise und fertig. Hier muss man für jeden einzelnen Wert extra eine Methode aufrufen und das ganze noch über einen TRY-ENDTRY-CATCH-Block absichern, damit einem der Mist nicht dumpen kann.


Nein. Man kann einen großen drumrum bauen nach dem Motto "ich weise jetzt alle Feldeigenschaften zu, wenn (irgend)was dabei schiefgeht, ist das ein Fehler". Man kann mit Ausnahmeklassen irre Sachen machen, wenn man ein bisschen kreativ ist. Früher hab ich die Dinger gehasst wie die Pest, aber seit ich z. B. weiß, wie ich komplette Protokolle durch Verschachteln von Ausnahmen zusammenbauen kann, die ich dann einmal "auspacke" und ins Anwenderlog schreibe (mit einer generischen Klasse, die ich einmal geschrieben habe für das ganze System), bin ich ein echter Fan davon, weil ich dazu nix mehr selbst machen muss.


Ralf
Bild Ralf WenzelHeuristika
SAP-Development • Datenschutzberatung
PublikationenUngarische NotationXing
ralf.wenzel
Top Expert
 
Beiträge: 2636
Registriert: 18.09.2004, 13:03
Wohnort: Hamburg
Dank erhalten: 116 mal
Ich bin: Freiberufler/in

Nächste

Zurück zu ABAP® für Anfänger

  Aktuelle Beiträge   
gelöst Protokoll vergangener RFC Aufrufe
vor 16 Stunden von Dele 3 Antw.
BREAK-POINT-IDs verwenden
vor 15 Stunden von ralf.wenzel 2 Antw.
MEREQ001 Zusatzfelder ausblenden
vor 3 Tagen von SAP4Echo 0 Antw.
gelöst Z Tabelle Key Feld ändern
vor 3 Tagen von DeathAndPain 3 Antw.
gelöst Funktionsbaustein EXIT_SAPLCORF_404 in Transaktion COR6N
vor 20 Stunden von SAP_ENTWICKLER 2 Antw.

  Ähnliche Beiträge beta
alv grid interne tabelle mit transparenter tabelle abgleiche
07.05.2008, 07:30 von hadde85 10 Antw.
Daten aus DB-Tabelle in interne Tabelle kopieren
07.02.2008, 12:38 von TWP 1 Antw.
Vergleich interne Tabelle mit Datenbank Tabelle
27.01.2014, 14:14 von a-dead-trousers 2 Antw.
Aus Interne Tabelle in Datenbank Tabelle
30.01.2012, 16:46 von a-dead-trousers 3 Antw.
Tabelle in interne Tabelle kopieren
02.07.2017, 02:55 von sapyard 10 Antw.

 

Wer ist online?

Mitglieder in diesem Forum: Bing [Bot]

Feedback ...?

Was können wir verbessern? Hinterlasse deine Kontaktdaten, wenn du eine direkte Antwort möchtest.

... Absenden!