ALV Tree / List Tree?
7 Beiträge
•
Seite 1 von 1
7 Beiträge
Seite 1 von 1
Hallo,
ich bin noch ein ziemlicher ABAP-Anfänger und versuche gerade, mir einen Überblick über die Möglichkeiten zu verschaffen, eine Baumstruktur zu erstellen.
Das scheint sowohl mit dem ALV-Tree als auch mit dem List Tree zu gehen, die ja auch auf ähnliche Art und Weise konstruiert werden. Da ich im Prinzip nur eine Baumstruktur und keine zusätzlich angezeigte Tabelle (ALV) benötige, reicht ein List Tree vielleicht aus. Allerdings ist der Tree, den ich aufbauen möchte, etwas komplizierter:
es gibt drei verschiedene Ebenen: die oberste ist die Hauptkategorie, darunter folgen die Untergruppen und jede Untergruppe enthält wiederum mehrere Elemente. Es muss nun innerhalb jeder Untergruppe (mittlere Ebene) mindestens ein Element (unterste Ebene) ausgewählt werden, oder alternativ eine Checkbox "nicht zutreffend" auf der mittleren Ebene angekreuzt werden.
Für diese drei Ebenen soll es jeweils Tabellen geben, deren Einträge bei Bedarf geändert und ergänzt werden können, also eine Tabelle mit allen Hauptkategorien, dann pro Hauptkategorie eine Tabelle mit den Untergruppen und pro Untergruppe eine Tabelle mit den Elementen, bzw. vielleicht auch insgesamt nur drei Tabellen (eine pro Ebene) mit entsprechenden Zuordnungen.
Wenn nun Elemente im Tree ausgewählt wurden, sollen diese auch ans Programm übergeben werden, damit sie weiter verarbeitet werden können.
Daher nun meine Frage: ist für diese Aufgabenstellung ein ALV-Tree oder ein List Tree besser geeignet?
Beim ALV Tree gibt es ja GET_SELECTED_NODES bzw. GET_SELECTED_ITEM zum Auslesen der angeklickten Elemente im Tree; ist dies z.B. auch mit dem einfachen List Tree möglich?
Ich würde mich freuen, wenn mir jemand ein paar Tipps geben könnte, in welches Thema ich mich einarbeiten sollte, um einen solchen Tree aufzubauen. Im Moment fehlt mir einfach noch der Überblick, um das Ganze beurteilen zu können.
Viele Grüße,
wega
ich bin noch ein ziemlicher ABAP-Anfänger und versuche gerade, mir einen Überblick über die Möglichkeiten zu verschaffen, eine Baumstruktur zu erstellen.
Das scheint sowohl mit dem ALV-Tree als auch mit dem List Tree zu gehen, die ja auch auf ähnliche Art und Weise konstruiert werden. Da ich im Prinzip nur eine Baumstruktur und keine zusätzlich angezeigte Tabelle (ALV) benötige, reicht ein List Tree vielleicht aus. Allerdings ist der Tree, den ich aufbauen möchte, etwas komplizierter:
es gibt drei verschiedene Ebenen: die oberste ist die Hauptkategorie, darunter folgen die Untergruppen und jede Untergruppe enthält wiederum mehrere Elemente. Es muss nun innerhalb jeder Untergruppe (mittlere Ebene) mindestens ein Element (unterste Ebene) ausgewählt werden, oder alternativ eine Checkbox "nicht zutreffend" auf der mittleren Ebene angekreuzt werden.
Für diese drei Ebenen soll es jeweils Tabellen geben, deren Einträge bei Bedarf geändert und ergänzt werden können, also eine Tabelle mit allen Hauptkategorien, dann pro Hauptkategorie eine Tabelle mit den Untergruppen und pro Untergruppe eine Tabelle mit den Elementen, bzw. vielleicht auch insgesamt nur drei Tabellen (eine pro Ebene) mit entsprechenden Zuordnungen.
Wenn nun Elemente im Tree ausgewählt wurden, sollen diese auch ans Programm übergeben werden, damit sie weiter verarbeitet werden können.
Daher nun meine Frage: ist für diese Aufgabenstellung ein ALV-Tree oder ein List Tree besser geeignet?
Beim ALV Tree gibt es ja GET_SELECTED_NODES bzw. GET_SELECTED_ITEM zum Auslesen der angeklickten Elemente im Tree; ist dies z.B. auch mit dem einfachen List Tree möglich?
Ich würde mich freuen, wenn mir jemand ein paar Tipps geben könnte, in welches Thema ich mich einarbeiten sollte, um einen solchen Tree aufzubauen. Im Moment fehlt mir einfach noch der Überblick, um das Ganze beurteilen zu können.
Viele Grüße,
wega
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!
Also ich persönlich halte mich von den (ALV)Tree-Controls fern.
Ich würde dir eher die Tree-Model-Klassen empfehlen.
Die gibts auch in List/Item und Column Ausprägung.
Der Vorteil bei den Model-Klassen ist, das du einen bel. langen String als Knoten-Namen verwenden kannst.
Bei den Control-Klassen bist du glaub ich auf 10-20 Zeichen beschränkt.
Intern bauen dann die Model-Klassen, aber trotzdem ein Control auf, dass du zur Anzeige bringen kannst (CREATE_TREE_CONTROL)
Ein weiterer großer Benefit der Model-Klassen ist außerdem, dass sie keine Kurzdumps verursachen wenn du einen Fehler in der Struktur deiner Knoten (Hierarchie fehlerhaft, Parent-Knoten existiert nicht, usw.) hast, sondern sie geben eine detailierte Meldung aus, anhand der du sofort ablesen kannst wo der Fehler liegt.
Nun zu deinem Problem:
Ich würde nur eine Tabelle machen.
Den Schlüssel für die Knoten kannst du dann so aufbauen
Und wenn du aus dem Knotenschlüssel wieder den Zugriffsschlüssel für die tabelle haben willst
Wie gesagt, dass geht nur bei den Tree-Modell-Klassen weil die einen bel. langen Schlüssel ermöglichen.
Bei den Control-Klassen musst du zusätzlich noch eine Mapping zwischen Tabellenschlüssel und Knotenschlüssel einbauen.
lg ADT
P.S.: Für Fortgeschrittene: Bei den Tree-Modell-Klassen könntest man sogar theoretisch ohne interne Tabelle auskommen. Die bieten nämlich bei den Knoten die Möglichkeit an ein "USEROBJECT" zu speichern. Da könnte man dann je Knoten die Datenzeilen der Tabelle ablegen. Nach der ganzen Verarbeitung muss man dann nur noch aus der Knotenliste wieder all jene mit einen hinterlegten Objekt auslesen und daraus wieder eine Daten-Tabelle zusammenbauen.
Also ich persönlich halte mich von den (ALV)Tree-Controls fern.
Ich würde dir eher die Tree-Model-Klassen empfehlen.
Die gibts auch in List/Item und Column Ausprägung.
Der Vorteil bei den Model-Klassen ist, das du einen bel. langen String als Knoten-Namen verwenden kannst.
Bei den Control-Klassen bist du glaub ich auf 10-20 Zeichen beschränkt.
Intern bauen dann die Model-Klassen, aber trotzdem ein Control auf, dass du zur Anzeige bringen kannst (CREATE_TREE_CONTROL)
Ein weiterer großer Benefit der Model-Klassen ist außerdem, dass sie keine Kurzdumps verursachen wenn du einen Fehler in der Struktur deiner Knoten (Hierarchie fehlerhaft, Parent-Knoten existiert nicht, usw.) hast, sondern sie geben eine detailierte Meldung aus, anhand der du sofort ablesen kannst wo der Fehler liegt.
Nun zu deinem Problem:
Ich würde nur eine Tabelle machen.
Code: Alles auswählen.
types begin of ts_data,
main type string, "Hauptkategorie
sub type string, "Unterkategorie
appl type abap_bool, "nicht zutreffend
item type string, "Eintrag
value type abap_bool, "der Wert wurde ausgewählt
end of ts_dataCode: Alles auswählen.
concatenate <ls_data>-main <ls_data>-sub <ls_data>-item into ld_key separated by '_'.Code: Alles auswählen.
split ld_key at '_' into <ls_data>-main <ls_data>-sub <ls_data>-item.Bei den Control-Klassen musst du zusätzlich noch eine Mapping zwischen Tabellenschlüssel und Knotenschlüssel einbauen.
lg ADT
P.S.: Für Fortgeschrittene: Bei den Tree-Modell-Klassen könntest man sogar theoretisch ohne interne Tabelle auskommen. Die bieten nämlich bei den Knoten die Möglichkeit an ein "USEROBJECT" zu speichern. Da könnte man dann je Knoten die Datenzeilen der Tabelle ablegen. Nach der ganzen Verarbeitung muss man dann nur noch aus der Knotenliste wieder all jene mit einen hinterlegten Objekt auslesen und daraus wieder eine Daten-Tabelle zusammenbauen.
Folgende Benutzer bedankten sich beim Autor a-dead-trousers für den Beitrag:
wega83
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
Danke, das ist schon mal ein sehr hilfreicher Tipp! 
Ich habe mir jetzt mal ein paar Beispielprogramme dazu angesehen (z.B. SAPTLIST_TREE_MODEL_DEMO, SAPSIMPLE_TREE_MODEL_DEMO und SAPCOLUMN_TREE_MODEL_DEMO) und es auch schon geschafft, sie zu kopieren und eigene Tabelleneinträge in den Tree einzubauen.
Allerdings sieht es für mich so aus, als könnte man nur einen einzigen übergeordneten Ordner erstellen (Root) und darunter zwei Ebenen (Child und darunter noch eine Ebene mit Items). Ich bräuchte aber insgesamt drei Ebenen, also auch die Möglichkeit, mehrere Ordner auf Root-Ebene zu haben. Habe ich da was übersehen oder ist das mit den Tree-Model-Klassen nicht möglich?
Danke und viele Grüße,
wega
Ich habe mir jetzt mal ein paar Beispielprogramme dazu angesehen (z.B. SAPTLIST_TREE_MODEL_DEMO, SAPSIMPLE_TREE_MODEL_DEMO und SAPCOLUMN_TREE_MODEL_DEMO) und es auch schon geschafft, sie zu kopieren und eigene Tabelleneinträge in den Tree einzubauen.
Allerdings sieht es für mich so aus, als könnte man nur einen einzigen übergeordneten Ordner erstellen (Root) und darunter zwei Ebenen (Child und darunter noch eine Ebene mit Items). Ich bräuchte aber insgesamt drei Ebenen, also auch die Möglichkeit, mehrere Ordner auf Root-Ebene zu haben. Habe ich da was übersehen oder ist das mit den Tree-Model-Klassen nicht möglich?
Danke und viele Grüße,
wega
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Du musst nur mehrere Root-Knoten anlegen (RELATKEY = space).
Wichtig ist außerdem auf die RELATSHIP zu achten:
Die Knoten werden der Reihe nach so wie sie an das Modell übergeben werden (Reihenfolge der internen Tabelle bei ADD_NODES bzw Reihenfolge der ADD_NODE-Aufrufe) angelegt.
d.h. bei RELATKEY = xyz und RELATSHIP = cl_tree_model=>relat_prev_sibling wird der neue Knoten genau VOR dem Knoten xyz eingefügt, dieser muss aber schon existieren.
Ich verwend der Einfachheit halber immer cl_tree_model=>relat_last_child.
Damit ist gewährleistet, wenn ich die Daten per Tabelle an das Model schicke, dass die Reihenfolge im Tree der Tabellensortierung entspricht.
lg ADT
Wichtig ist außerdem auf die RELATSHIP zu achten:
Die Knoten werden der Reihe nach so wie sie an das Modell übergeben werden (Reihenfolge der internen Tabelle bei ADD_NODES bzw Reihenfolge der ADD_NODE-Aufrufe) angelegt.
d.h. bei RELATKEY = xyz und RELATSHIP = cl_tree_model=>relat_prev_sibling wird der neue Knoten genau VOR dem Knoten xyz eingefügt, dieser muss aber schon existieren.
Ich verwend der Einfachheit halber immer cl_tree_model=>relat_last_child.
Damit ist gewährleistet, wenn ich die Daten per Tabelle an das Model schicke, dass die Reihenfolge im Tree der Tabellensortierung entspricht.
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
Super, vielen Dank! Mit relative_node_key = ' ' funktioniert es!
Man kann außerdem auch die Ordnersymbole mit dem Parameter "image" durch Icons ersetzen, so wie ich es brauche. Das habe ich gerade schon erfolgreich getestet!
Eine Checkbox (wie ich sie auf der mittleren Ebene gerne hätte) kann man bei diesem einfachen Tree Model aber nicht einbauen, oder? Diese sollte rechts neben dem entsprechenden Ordner angezeigt werden.
Viele Grüße,
wega
Man kann außerdem auch die Ordnersymbole mit dem Parameter "image" durch Icons ersetzen, so wie ich es brauche. Das habe ich gerade schon erfolgreich getestet!
Eine Checkbox (wie ich sie auf der mittleren Ebene gerne hätte) kann man bei diesem einfachen Tree Model aber nicht einbauen, oder? Diese sollte rechts neben dem entsprechenden Ordner angezeigt werden.
Viele Grüße,
wega
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Bin mir nicht sicher, aber das ist glaub ich erst ab dem Item-Model möglich.
(ITEM-CLASS = CL_ITEM_TREE_MODEL=>ITEM_CLASS_CHECKBOX)
lg ADT
EDIT: Post 404 = "not found"
(ITEM-CLASS = CL_ITEM_TREE_MODEL=>ITEM_CLASS_CHECKBOX)
lg ADT
EDIT: Post 404 = "not found"
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
1
Antw.
Antw.
1732
Views
Views
1
Antw.
Antw.
1454
Views
Views
1
Antw.
Antw.
1549
Views
Views
3
Antw.
Antw.
2757
Views
Views
5
Antw.
Antw.
3669
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 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151
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 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151