Wann kann man boolesche Werte in IFs direkt nutzen?

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

ralf.wenzel hat geschrieben:

Daniel hat geschrieben:Das wovon 'die SAP" abrät ist das was das SAP-System ausmacht.

Weil die Zeiten sich geändert haben. Die Zeit der immer schnelleren Pferde ist vorbei, wir wechseln gerade zum Auto. Die sind laut und stinken, die scheuen nicht vor anderen Verkehrsteilnehmern sondern nieten sie im Zweifel um - aber mit schnelleren Pferden kommen wir nicht weiter. Da kann man Pferde viel schöner finden als Autos, es führt kein Weg dran vorbei.

Hier geht es weder um Pferde noch um Autos.
Es geht um ein System daß vor allem wegen seiner
Zuverlässigkeit zum Industriestandard geworden ist.

ralf.wenzel hat geschrieben:

Daniel hat geschrieben:Die Ratschläge von 'der SAP' sind in Wahrheit die Ratschläge von
Anfängern die zufällig im ABAP-Team gelandet sind und das noch
nicht verstanden haben und deshalb krampfhaft versuchen aus
ABAP Java zu machen.

Ganz ehrlich: Um deine abfällige Art, über die Arbeit anderer zu denken und zu schreiben, beneide ich dich nicht. Die sitzen ja bei der SAP nicht rum und denken "hach, uns ist grad fad, lass uns doch mal neue Befehle ausdenken". Das sind auch keine Idioten, sondern Menschen mit einem langfristigen Plan, die sich sehr wohl was dabei denken. Man sollte sich mit denen ruhig mal unterhalten.

Ich habe massive Zweifel an dieser Aussage. Heute ist jeder
der eine Idee vorträgt erst mal hipp - egal was die taugt.
Früher gab es dort Menschen mit einem langfristigen Plan.
Genau die fehlen mir heute.

Wenn ich dann solche Meldungen sehe: in einem Coding das syntaktisch völlig sauber ist
Und das ist noch ein eher harmloses Beispiel.

ralf.wenzel hat geschrieben:Das, was man heute an Anwendungen schreibt (auch bei der SAP - aber nicht nur) unterscheidet sich fundamental von dem, was zu den Zeiten entwickelt wurde, als diese Jugendsünden entstanden.

Blödsinn. Auch heute geht es noch um Betriebswirtschaft.
Naja - und viel Bling-Bling.

ralf.wenzel hat geschrieben:Wer Programmiersprachen kennt, weiß, dass man gewisse Dinge nicht macht. Zum Beispiel dass "A+1" eine völlig andere Bedeutung hat als "A + 1".

Wer Computertechnik kennt weis daß der Name einer Variablen nichts anderes
als die Repräsentation einer Speicheradresse ist welche für Menschen besser
lesbar sind als die reinen Adressen wie Maschinen Sie verwenden.
A+1 ist also nichts anderes als 65340+1. Völlig naheliegende Syntax. A + 1 ist in
der ABAP-Syntax nur in der Form COMPUTE Z = A + 1 vorgesehen. Das ist völlig
eindeutig. Erst die "Neue Syntax" hat das Konstrukt in anderem Zusammenhang
erlaubt. Der Ursprung ist also völlig sauber.

ralf.wenzel hat geschrieben:Das war egal, solange SAP-Entwicklung eine Nische war, wo man in SAP für die SAPGUI entwickelt hat und fertig. Man sollte nicht vergessen: Die SAP galt sehr, sehr lange als OO-Feindgebiet - bis die Kunden (!) dazu drängten, ich kann mich an diese Zeit noch gut erinnern.

Kein Kunde hat die SAP zu 00 gedrängt. Ganz im Gegenteil haben viele Kunden
sogar Berater die 00 programmieren abgelehnt.

ralf.wenzel hat geschrieben:Irgendwann ist ein Grad von Komplexität erreicht, dass jemand sagt "ich glaube, mit OO-Abbildung wird das Ganze wartbarer, weil die Darstellung nicht so 'computerlastig' ist, sondern viel näher an der realen Welt" (gerade das ist ein großer Teil des Charmes von OO, weil wir von "zustandsbehafteten Objekten" umgeben sind).

Zunächst mal ist da gar nicht besser wartbar. Du verwechselst noch immer den
Ansatz von 00 mit Modularisierung.
Und in der realen Welt ist ein Tischler der ein Brett mit einem Hobel bearbeitet.
Und dann noch eins. Und später nimmt er einen Bohrer...
Objekte machen Sinn wenn man die Position von allen Sternen darstellen will.
Ändert man die globale Zeit nehmen alle Sterne Ihre zugehörige Position ein.
Genau das geht mit SAP-00 nicht. Die schlechtest mögliche Implementierung. Die
ist ohnehin nur aus Marketing-Gründen überhaupt gemacht worden. In einem System
für betriebswirtschaftliche Anwendungen gibt es nur sehr wenige wirklich sinnvolle
Stellen für die Anwendung von 00. Dort soll man es verwenden - aber nicht als
Allheilmittel.

ralf.wenzel hat geschrieben:Das "ABAP von früher" ist für derart komplexe Anwendungen wie das EWM oder die genannten etwa so geeignet wie Assembler als Programmiersprache für das SAP selbst. Geht auch, aber nur mit heftigen Schmerzen.

Selbst mit Assembler ging das erstaunlich gut
Und ein EWM ist eine relativ triviale Anwendung.

ralf.wenzel hat geschrieben:Es gab Mechanismen, die zu ihrer Zeit ihre Berechtigung hatten, sich aber einfach überlebt haben. Beispiel: Ich bestreite nicht, dass das Konzept mit Dynpros sinnvoll war, als die Rechnerleistung noch deutlich niedriger war als jetzt und eh jeder Client unter Windows lief. Heute ist das nicht mehr zeitgemäß, einen speziellen SAP-Client zu benötigen, weil die Gerätelandschaft deutlich vielfältiger ist als früher.

Solange es um die interne Datenverarbeitung in einem Unternehmen geht ist
ein eigener Client keine schlechte Lösung.
Ganz im Gegenteil zu der Idee einen HTML-Browser für solch eine Aufgabe zu
missbrauchen. Mal davon abgesehen daß er höchst ungeeignet ist handelt es sich
um die am meisten angegriffenen Anwendungen überhaupt. Niemand kann sagen
wer noch alles mitliest. Die mit großem Abstand meisten Abstürze verursachen
diese Browser auch noch. Das ist das genaue Gegenteil einer stabilen Landschaft.

ralf.wenzel hat geschrieben:Schon Barcodeleser sind heute oft keine Barcodeleser mehr,

Kann man ja einbinden. Dann aber über eine Schnittstelle die den Zugriff sehr
restriktiv limitiert. So hat SAP das ja auch implementiert. Hat nur nicht jeder
verstanden

ralf.wenzel hat geschrieben: Blickt man dann in Richtung S/4, stellt man fest, dass man es plötzlich mit Statistiken zu tun hat, für die das Programm mit R zusammenarbeiten muss; Statistiken, die wir Entwickler erstmal verstehen lernen müssen. Vorausschauende Wartung oder Bonitäts-Scoring ist da ein wichtiges Stichwort. Und R ist nur ein Beispiel unter vielen. Es wird alles bunter und vielfältiger, da kann ABAP nicht stehenbleiben.

Man darf nicht stehen bleiben. Aber die VW-Technik ist völlig daneben.
Von SAP erwarte ich nicht daß Sie der Smartfon-Technik hinterherhecheln
sondern stabile Prozesse ohne Brimborium. Bunte Bildchen können andere
besser.

ralf.wenzel hat geschrieben:

Daniel hat geschrieben:

ralf.wenzel hat geschrieben: *sry, Daniel, aber den hast du dir selbst eingeschenkt

Ich habe in diesem Thread noch nix gepostet - was habe ich
also verbrochen?

Wenn du ein bisschen nachdenkst, kommst du drauf - auch wenn das schon ne Weile her ist
Ralf

Keine Ahnung worum es geht.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Bei dieser Aussage muss ich aber laut lachen :

Und dass ein Browser ungeeigneterer sein soll als eine SAPGUI, halte ich für ein Gerücht. Schon die Plattformabhängigkeit auf dem Client wird zunehmend zu einem Problem, Browser gibt es für jede beliebige Plattform. Und das Gerät, mit dem eine zunehmende Anzahl von Anwendern arbeitet, ist nunmal kein WindowsPC.

WebDynpro und auch SAPUI5 wird nicht auf allen Systemen/Browsern unterstützt, zum Teil sucht man sich einen Wolf bis ein Fehler gefunden wird, manchmal wünscht man sich dann wieder den guten alten SAPGUi
/Edwin

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Ich denke, die Wahrheit liegt in der Mitte und werde mal versuchen, hier den Salomon raushängen zu lassen.

Kein Kunde hat die SAP zu 00 gedrängt.

Ich liebe es, wie Du 00 statt OO schreibst.
https://goo.gl/JkEaVs
SCNR

In einem System für betriebswirtschaftliche Anwendungen gibt es nur sehr wenige wirklich sinnvolle Stellen für die Anwendung von 00. Dort soll man es verwenden - aber nicht als Allheilmittel.

Genau das ist ein Knackpunkt, den ich auch so sehe. Der Entwicklungsaufwand ist an vielen Stellen um Größenordnungen höher, auch wenn ich weiß, dass Ralf jetzt wieder beteuert, was man alles nicht mehr machen muss. In den allermeisten Fällen wäre dieses Ziel mit Funktionsbausteinen auch erreichbar. Tatsächlich haben Funktionsbausteine viele Eigenschaften von Objekten, sind aber deutlich besser zu handhaben. Dass man sie noch verbessern/modernisieren könnte, ist richtig, nur macht die SAP es halt nicht, weil sie auf OO setzt.

Bei großen Projekten mag gut dokumentiertes OO Sinn machen. Ich persönlich habe freilich noch kein gut dokumentiertes OO zu Gesicht bekommen, und schlecht dokumentiertes OO ist ein Albtraum.

Davon abgesehen sind für meinen Arbeitsalltag große Projekte eine Seltenheit. Für die täglichen Anforderungen (Reports kleiner bis mittlerer Größe etc.) sind die Mittel, die OO bereitstellt, hoffnungsloser Overkill, mit dem man wesentlich länger braucht, aber nichts gewinnt, auch und gerade nicht hinsichtlich der Wartbarkeit. Der Anspruch von OO, Programmierer zu disziplinierterem Arbeiten zu zwingen, gerade auch hinsichtlich der Kapselung, ist eine Illusion. Man kann Programmierer nicht zu diszipliniertem Arbeiten zwingen. Man kann sich nur von Programmierern trennen, die sich weigern, es von sich aus zu machen.

Solange es um die interne Datenverarbeitung in einem Unternehmen geht ist ein eigener Client keine schlechte Lösung.
Ganz im Gegenteil zu der Idee einen HTML-Browser für solch eine Aufgabe zu missbrauchen.

Das finde ich allerdings auch. Allein die Antwortzeiten, die durch die HTML-Aufbereitung entstehen, sind oft indiskutabel. Wer kennt sie noch, die alte Regel, dass ein Anwender ein System ab einer Sekunde Antwortzeit als langsam empfindet? Eine Sekunde ist doch bei jeglichem HTML-basierten Geraffel gar nichts! Den Anwendern ist hier eine hohe Leidensfähigkeit auferlegt worden.

Wir arbeiten hier mit dem Solution Manager der SAP. Eigentlich eine tolle Sache für das Transportsystem (und die ZBV), aber was ich hier nach jedem einzelnen Klick warten muss, bis endlich die Antwort kommt... und wenn man sich mal verklickt hat und auf die Browserfunktion "Zurück" klickt, dann startet die Anmeldung durch, weil das Browser-Back nicht unterstützt wird. Jegliche HTML-basierte Lösung müsste IMHO auch das "Zurück" und "Vorwärts" der Browser (unter Nutzung von dessen Cache) unterstützen. Das kann aber kaum jemand. Dass es geht, zeigt z.B. Google. In Gmail, Google Sheets usw. funktioniert der Kram erstaunlich gut.

Von SAP erwarte ich nicht daß Sie der Smartfon-Technik hinterherhecheln sondern stabile Prozesse ohne Brimborium. Bunte Bildchen können andere besser.

Leider werden bunte Bildchen heute aber erwartet. Wenn bei einem Kunden für eine betriebswirtschaftliche Lösung drei Systeme vorgeführt werden, und zwei davon haben hippe Optik und volle Smartphone-Unterstützung, während SAP mit dem drögen SAPGui-Bildschirm daherkommt, dann fliegt es bei der Auswahl sofort hinten runter wegen mangelnder Anwenderfreundlichkeit. Insofern ist es schon richtig, dass die SAP das auch unterstützt. Aber irgendwie müssten sie die Anbindung wesentlich besser hinkriegen. Das ist in der Pflege alles zu kompliziert - nicht zuletzt wegen der Objektorientierung in Fiori, wo man sich zuweilen die Karten legt, warum die Kachel denn jetzt immer noch nicht angezeigt wird. Außerdem hat man halt die HTML-Antwortzeiten (die konkurrierende Systeme freilich auch haben). Und es müsste sich wie eine native HTML-Anwendung anfühlen, also mit funktionierendem "Browser Back" und funktionierenden Bookmarks auf beliebigen Seiten. Auch das funktioniert bei Google beeindruckend gut. Die scheinen mir so ziemlich die einzigen zu sein, die verstanden haben, dass man die HTML-Umsetzung nicht nur halbherzig ausführen darf, wenn man darauf setzen möchte. Dabei ist mir klar, dass die Umsetzung solcher Funktionalitäten extrem schwer sein muss.

Da wird dann das SAP-Transportsystem zum "schlechtesten, was ich je gesehen habe". Es hat seine Tücken, aber das liegt auch an der Komplexität der Aufgabe. Es gibt Entwicklungslandschaften, die froh wären über soviel Automatismus beim Deployment. Wie jedes komplexe Werkzeug bedingt es aber eine gewisse, standardisierte Arbeitsweise.

Die man mit dem Solution Manager noch viel besser standardisieren und in auditfähige Bahnen lenken kann. Arbeitet eigentlich sonst noch jemand damit?

Die "neue" Syntax Z = A + 1. Die ist aber nicht wirklich neu, dass COMPUTE weggelassen werden kann, ist schon sehr, sehr lange so. Ich habe das Schlüsselwort nach meiner Erinnerung noch nie verwendet und ich programmiere seit 1996 in ABAP.

An der Stelle bin ich auch der Meinung, dass eine solch triviale Abstrahierung jedem Programmierer zuzumuten ist und finde es auch völlig unproblematisch, dass der Zuweisungsoperator und der Vergleichsoperator beide gleich sind. Wer das nicht auseinandergehalten bekommt, weil er nicht sieht, ob da ein IF (oder ein vergleichbares syntaktisches Konstrukt) davorsteht, der sollte sich einen anderen Job suchen.

Der C64 hatte in seinem (damals als primitiv, aber schnell geltenden) Basic auch schon eine COMPUTE-Anweisung (nur dass sie LET hieß). Und auch bei diesem konnte man sie schon ohne Nachteile weglassen, weswegen niemand sie verwendet hat.

Schon die Plattformabhängigkeit auf dem Client wird zunehmend zu einem Problem, Browser gibt es für jede beliebige Plattform.

Java auch, und das Java-GUI ist ja fertig. Es kann nicht alles, was das Gui für Windows kann, aber das liegt nur daran, dass die SAP da nicht genug Energie reinsteckt. Man könnte sogar so weit gehen, nur noch Java zu unterstützen.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Darum geht es nicht, es geht um die Eindeutigkeit von Codingstrecken. Eine Anweisung, die im einen Zusammenhang das eine und in einem anderen Kontext was anderes bedeutet, ist in meinen Augen nicht zielführend.

Das finde ich eine bürokratische Haltung. Eine Anweisung, bei der ein halbwegs intelligenter Programmierer in jedem Kontext (außer vielleicht bei Missbrauch der neuen 7.40-Konstrukte) sieht, was sie bedeutet, ist zielführend.

Aha, und die JavaGUI passt sich automatisch der Displaygröße an oder ändert die UI, wenn du das Display drehst?

Ich habe keine Zweifel, dass man das auch hinkriegen würde. Java auf Mobilgeräten ist ja absoluter Alltag. Der Engpass ist nicht Java, sondern die Bereitschaft der SAP, hier Energie zu investieren.

Tatsächlich würde ich so eine Funktionalität sogar für eine interessante Evolution des SAPGui halten.

Ralf *raus aus dem Thread - wie angekündigt

Willkommen zurück! Ich habe keine Zweifel, dass Du das hier liest. Wer mit Pauken und Trompeten seinen Abgang aus einem Thread ankündigt, um sich so selber das letzte Wort einzuräumen (was übrigens sehr schlechter Diskussionsstil ist), der kommt immer zurück, um die Reaktionen zu lesen.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Hm, bei MARA-MATNR und MARA - MATNR gehe ich gerade noch mit, wobei ich denke, die Erfordernis von Leerzeichen bei Rechenoperationen ist schon etwas, was man verinnerlichen kann. Aber bei COMMIT WORK AND WAIT sollte selbst der dümmste Programmierer nicht auf den Gedanken kommen, dass es hier um ein logisches AND gehen würde. Problematischer finde ich da schon den Ausdruck BETWEEN 1 AND 3, denn der stellt ja selbst ein boolesches Konstrukt dar, das selbst wieder per AND mit anderen Bedingungen verknüpft werden kann ( IF x BETWEEN 1 AND 3 AND y > 2 ). Das hätte ich an Stelle der SAP wohl anders implementiert. Aber das ist ein eher exotischer Einzelfall.

Oder dass der Befehl "MODIFY" einfach je nach Kontext was völlig anderes macht.

An der Stelle gebe ich Dir uneingeschränkt recht. Dass der MODIFY für interne Tabellen und der für Datenbanktabellen dieselbe Syntax haben und ABAP eine interne Tabelle nimmt, wenn es sie gibt und andernfalls halt auf die Datenbank schreibt, das ist extrem unglücklich gelöst. Ich finde es zwar ganz nett, einen Befehl zu haben, der eigenintelligent INSERT und UPDATE kombiniert, aber man hätte ein anderes Schlüsselwort dafür nehmen sollen (z.B. CHANGE). Oder ein Zusatzwort, etwa MODIFY DATABASE TABLE.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Ich bereue stark, gegen meine Regel verstoßen zu haben, keine Meinungen mehr zu posten, sondern nur noch Fakten. Aber auch wenn ich zum Meinungszwist (wie angekündigt) nichts mehr sagen werde (weil wir uns da eh nicht einig werden und jeder so seine Vorlieben hat):

Daniel hat geschrieben:

ralf.wenzel hat geschrieben:Da wird dann das SAP-Transportsystem zum "schlechtesten, was ich je gesehen habe".

Auch das habe ich in dieser Form nicht gesagt.

Daniel, ich bitte dich. Es waren bestimmt 20 Leute dabei, einige davon Mitleser. Aber egal, es bestärkt mich in meiner Entscheidung, mich hier rauszuhalten.


Ralf

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

DeathAndPain hat geschrieben:Für die täglichen Anforderungen (Reports kleiner bis mittlerer Größe etc.) sind die Mittel, die OO bereitstellt, hoffnungsloser Overkill, mit dem man wesentlich länger braucht, aber nichts gewinnt, auch und gerade nicht hinsichtlich der Wartbarkeit.

Das sehe ich teilweise anders. Den Overkill, den ein echtes OO-Konzept in einem solchen Programm bringt kann ich ja noch nachvollziehen. Aber da je explizit die Mittel, die OO bereitstellt angesprochen wurden und Methoden nun einmal zu diesen gehören möchte ich doch widersprechen. Gerade durch die nachträgliche Erweiterbarkeit auch eines kleinen Programms durch optionale Parameter an Methoden sind diese herkömmlichen FORM-Routinen einfach überlegen. Selbiges gilt in meinen Augen auch für die Verwendung funktionaler Methoden in Aufrufen. Schon ein "lv_text = get_longtext( irgendwas )" finde ich einfach schöner als "PERFORM getlongtext USING irgendwas CHANGING lv_text" - und wenn man das Resultat dann auch noch weiterverwenden kann - etwa oder als Parameter in Stringausdrücken wie z.B. lv_ausgabe = |{ irgendwas }({ get_longtext( irgendwas ) })| leuchten mir doch die Augen.

Re: Wann kann man boolesche Werte in IFs direkt nutzen?

Ehe ich explodiere, muss ich doch wieder rückfällig werden....

DeathAndPain hat geschrieben:

Selbiges gilt in meinen Augen auch für die Verwendung funktionaler Methoden in Aufrufen. Schon ein "lv_text = get_longtext( irgendwas )" finde ich einfach schöner als "PERFORM getlongtext USING irgendwas CHANGING lv_text" - und wenn man das Resultat dann auch noch weiterverwenden kann - etwa oder als Parameter in Stringausdrücken wie z.B. lv_ausgabe = |{ irgendwas }({ get_longtext( irgendwas ) })| leuchten mir doch die Augen.

Funktionale Methoden baue ich auch dann und wann mal in meine Programme ein, weil die Aufrufstellen schön übersichtlch aussehen. Doch der Preis, den man dafür zahlt, ist hoch....

Hier gab es mal ein sehr einfaches Beispiel, damit wir hier nicht so im luftleeren Raum diskutieren:

Beispiel für eine Funktionale Methode aus der Praxis

Das ist eine funktionale Methode, die nur den conversion exit aufruft. Die schreibt man einmal und genießt die (in meinen Augen durchaus vorhandenen Vorteile) immer wieder. Ich gebe dir vollkommen recht, dass sowas lokal implementiert schwer zu begründen ist. Aber auf diese Idee wären black_adept und ich auch nicht gekommen.

"Völliger Unfug" sagt Daniel dazu wörtlich. Ich habe ihm geschrieben, in welchem Kontext das sinnvoll ist, weil man dann eben nicht diesen coding-zerschneidenden "geschwätzigen Codingblock" ggf. mit Hilfsvariablen einbauen muss (den ICH subjektiv als leseerschwerend empfinde, muss nicht jeder so sehen), sondern das Ergebnis dieser Methode an funktionalen Operandenpositionen einsetzen kann. Für bestimmte Konvertierungen ist es darüber hinaus sinnvoll, den Eingabewert zu verproben, damit kein Müll rauskommt, was man dann zentral einbauen kann. Aus diesen zwei Gründen habe ich in Absprache mit internen Entwicklern diese Klasse und auch die gezeigte Methode geschrieben (womit sich erklärt, warum ich so angepisst bin).

Das ist praktisch ein CONV für Konvertierungs-Exits mit Benefits. Das hat mit OO nichts zu tun, sondern nutzt einfach nur den Vorteil funktionaler Methoden.

Noch ein persönliches Wort zum verlinkten Posting, weil das wirklich beleidigend ist:

Man kann sagen "brauch ich nicht, ich habe es lieber geschwätzig", aber dem Entwickler Unfug zu unterstellen, weil er eine kürzere Schreibweise bevorzugt und vielleicht auch etwas langfristiger denkt, ist anmaßend, unverschämt und beleidigend. Erfahrenen Entwicklern unterstelle ich grundsätzlich zunächst immer, dass sie sich dabei was gedacht haben, was sie tun. Aber bestimmte Leute, die hier schreiben, als hätten sie das Rad erfunden, deklarieren einfach schnell alles als Unfug, was / wessen Kontext sie nicht verstehen. Alles Unfug - SAPUI5, OO, ABAP 7.40 mit seinen Kurzformen, Polymorphie. Und die bei der SAP, die das machen, haben nicht etwa eine unbekannte Motivation, sie sind Dilettanten, die keine Ahnung haben. Das ist der Grund, warum ich auf Pauschalverurteilungen von neuen Techniken ziemlich allergisch reagiere.

Das Problem ist: So kommt man nicht weiter. Ein Blutspendedienst will keinen PC zum Blutspendetermin schleppen, wenn ein Tablet für die Datenerfassung reicht und außerdem eine Kamera eingebaut ist, mit der man beliebige Bar-/QR-Codes lesen kann, die auf Blutspendeausweisen und Proben vorhanden sind. Die wollen sich nicht mit Treiberproblemen durch Barcodeleser herumärgern. Da kann man sich als Entwickler im Kreis drehen und Sch... schreien, der Anwender ist der Boss. Und der freut sich nen Keks, wenn man sein Leben einfacher macht. Wir sind nicht zu einem Selbstzweck da, sondern um die Wünsche des Anwenders so hochwertig wie möglich zu erfüllen. Und eine Vielzahl von Anwendern sind eben nicht mehr die, die den ganzen Tag am Windows-PC die SAPGUI bedienen. Ich bleibe bei meinem Beispiel: Schnellere Pferde sind irgendwann nicht mehr die Antwort.

Ja, das hat alles seine Tücken und man muss sich plötzlich mit Themen wie Sicherheit beschäftigen, aber das (Entwickler)leben ist kein Ponyhof und auch die SAP lernt dazu. Für jemanden mit einem Hammer ist jedes Problem ein Nagel. Aber Dynpros und SAPGUI sind eben nicht für alle (sondern für immer weniger Fälle) die Lösung für eine UI und ich bleibe dabei: Ich habe die Erfahrung gemacht, dass es durchaus SAP-Entwicklungen gibt, die in OO deutlich besser abgebildet sind als prozedural. Auch wenn bestimmte Leute das per Definition als Unfug bezeichnen mögen. Und auch die, dass eine gekapselte Business-Logik den Austausch der UI deutlich vereinfacht. Man schreibt und testet eben nicht alles neu. Das sind Projekterfahrungen aus der Praxis und eben kein Unfug.

Und er Witz von der Geschicht': Interessanterweise bekomme ICH hier immer wieder Mails, ICH möchte mich in meinem Ton mäßigen.


Ralf