Das ist aber keine reine Änderung im Datenmodell, sondern stellt den Prozess an sich komplett auf den Kopf.Daniel hat geschrieben:Es gibt da einen kleinen Unterschied zwischen Datenstruktur
und Datenmodell. Das verwechselst du gerade.
Wenn der Bestand nicht mehr nach Werk/Lagerort sondern
nach Lager (das mehrere Werke bedienen kann) geführt
wird ist alles Makulatur.
Vielleicht solltest du diese mal öfter posten, falls Du es nicht schon hast.ralf.wenzel hat geschrieben: Zurück zu Dynpros:
Aber schon der Umstand, dass "globale Variablen" (ich kann diesen Ausdruck schon nicht mehr hören) eingesetzt werden, macht jede Kapselung / Modularisierung zu einer Krücke.
Ich hab neulich zu einem Programmierer gesagt "Nein, keinen Report - machen Sie bitte eine objektorientierte Transaktion", weil man die gescheit modularisierten kann. Der hat mich angeguckt wie ein Auto, weil der gar nicht wusste, was das ist. Inzwischen muss ich keine Bilder mehr malen, mein iPad gibt genug schematische Darstellungen her, weil ich das ständig erkläre, wie man den Dialog vom Programm unabhängig macht.
Ralf
Ja, aber nicht zwangsläufig. Wenn der Reifen an meinem Auto platt ist, KANN das daran liegen, dass ich das Auto an eine Wand gesetzt habe. In diesem Falle brauche ich natürlich ein ganz neues Auto.Daniel hat geschrieben:Das hat eine Änderung im Datenmodell häufig zur Folge.
Klar kann man das alles machen. Aber in einem Selektionbild (also einem Dynpro) sind dann die Selektionsoptionen und Parameter auch wieder "global". Wie gesagt: Krücken. Die funktionieren, umgehen aber das eigentliche Konzept, (Stichwort Feldtransport).gtoXX hat geschrieben:Man braucht globale Variablen nur, wenn man Werte-Hilfen nicht dynamisch programmieren will. Wobei man das auch über eine Service-Klasse erledigen lassen könnte ...... Allerdings lässt sich ein Lokales Reportobjekt auch Problem im Shared Memory ablegen.
Code: Alles auswählen.
Ausgangsthema:
#
Code: Alles auswählen.
Aktuelles Thema
\_/
--(_)--
/ \ |> v-v-v-v |>
, , /_\ | | /_\
|\_/| | |'''''''''''| | |\
(q p),-| | || _ || | |'-._ ))
\_/_(/| | |#| | | ) '-.___//
--w-w---'-'----'-'----'-'----------'-----------ldb---
ralf.wenzel hat geschrieben:Klar kann man das alles machen. Aber in einem Selektionbild (also einem Dynpro) sind dann die Selektionsoptionen und Parameter auch wieder "global". Wie gesagt: Krücken. Die funktionieren, umgehen aber das eigentliche Konzept, (Stichwort Feldtransport).gtoXX hat geschrieben:Man braucht globale Variablen nur, wenn man Werte-Hilfen nicht dynamisch programmieren will. Wobei man das auch über eine Service-Klasse erledigen lassen könnte ...... Allerdings lässt sich ein Lokales Reportobjekt auch Problem im Shared Memory ablegen.
Dann lieber gar keinen Report....
Ralf
Siehe oben.gtoXX hat geschrieben:Selektionsoptionen und sind tatsächlich ein Teil, das man entweder nachbauen müsste oder global im Report hätte. Ob man sie nun sauber an den Constructor einer DB-Klasse oder der Reportklasse übergibt liegt an jedem selbst. Da nicht jeder mit WebDynpro glücklich ist, wird diese eine Krücke wohl bleiben.ralf.wenzel hat geschrieben:Dann lieber gar keinen Report....