Grafische Oberflächen statt 5250 Emulation

[RobertMack]

Ich als "Windows-Fan" kann mir nicht vorstellen, dass die damit schneller arbeiten.

Ich kenne einige Kunden-Mitarbeiter/innen die blind und in atemberaubenden Tempo green Screens befüllen, manchmal zwei bis drei Funktionstasten und Formate im Voraus. Die würden sich niemals irgendein Win-Klick-Gefummel andrehen lassen.

Aber wenn's bei Euch unbedingt sein muss, Brigittas aktuellstes Baby klingt äußerst interressant: http://www.wopixx.com/de/produkt

[Fuerchau]

Bei dem wopixx frage ich mich wo denn da der Oberflächendesigner und Codegenerator ist.
Nur mit Try und Error Bildschirme zu entwickeln finde ich schon aufwändig.
Da gibt es sicherlich elegantere Methoden.

Und was die Geschwindigkeit einer 5250-Erfassung angeht so ist die wirklich unschlagbar.
Unter Windows ist die Tastatur gesperrt wenn man nicht im Eingabefeld ist oder führt sogar zu unerwünschten Effekten.

[B.Hauser]

Bei dem wopixx frage ich mich wo denn da der Oberflächendesigner und Codegenerator ist.
Nur mit Try und Error Bildschirme zu entwickeln finde ich schon aufwändig.
Da gibt es sicherlich elegantere Methoden.

Baldur,
ich gehe mal stark davon aus, dass Du WOPiXX weder heruntergeladen noch ausprobiert hast!
Desweiteren wird beim Herunterladen eine 380-Seiten starke Dokumentation mitgeliefert. Daneben werden zwei Quellen-Templates (je eines für List/Subfile- und eines für Detail-Programme) bereitgestellt und mit ausgeliefert.
Sich einfach nur hinstellen und behaupten irgendetwas (das auch noch kostenlos! ist) und das man noch nichteinmal gesehen hat, nichts taugen kann, gilt nicht.

Es gibt außerdem noch die Möglichkeit sich in WOPiXX schulen zu lassen (im Gegensatz zum Tool und der Runtime ist dieser Service jedoch nicht kostenlos).

WOPiXX ist in erste Linie für klassische IBM i (RPG) Programmierer gedacht, die mit den vorhandenen Skills (ohne HTML, JavaScript etc. KnowHow) anstatt schwarz/grün Web-Programme erstellen wollen.
Wer natürlich anderes Know-How - PHP, Dot-Net, Java etc. der kann natürlich dieses nutzen und Web-Anwendungen anderweitig erstellen.

WOPiXX besteht aus 3 Blöcken, Administration, Engine und einer Funktions-Bibliothek (Service-Programme mit WOPiXX-Prozeduren).

Der Programmierer definiert durch den Aufruf von RPG/WOPiXX-Prozeduren welche Felder aus welcher Datei/Tabelle/View mit welcher Aufbereitungsoption (dafür stellen wir jede Menge Schlüssel-Worte bereit) angezeigt werden sollen.

Nachdem alle gewünschten Spalten, Filter, Kontext-Menü-Punkte und Buttons für eine List-Anzeige definiert sind, wird eine RPG-Funktion aufgerufen die das Ende der Erfassung kennzeichnet und die WOPiXX-Engine aktiviert. Die WOPiXX-Engine übernimmt und generiert aus den angegebenen Informationen mit Hilfe des DHTMLX-Framwork die entsprechende Web-Anzeige.

Nach einer Aktion in der generierten Web-Site (z.B. Klick auf einen in RPG-Programm definierten Button) übernimmt die Engine erneut, ruft das z.B. bei der Definition des Buttons oder Kontext-Menü-Punktes angegebene (RPG) Programm auf, über das dann die nächste Web-Site afubereitet udn gesteuert wird.
List-Anzeigen können auf diese Art- und Weise (abhängig von der Anzahl der Filter, Spalten, Kontext-Menü-Punkte und Buttons) mit 20-50 RPG-Statements generiert werden.

Für Detail-Anzeigen werden die aktuellen Abläufe der green/screen Dialog-Programme beibehalten:

• Einlesen-Datensatz (wie bisher)
• Definieren Ein-/Ausgabe-Felder (anstatt Umladen in die Display-File-Felder)
• Aufruf der Funktion Wx_GetChgInput (statt EXCFMT)
• Eingabe-Prüfung (im Fehlerfall erneute Anzeige - wie bisher - Im Fehlerfall wird allerdings eine Funktion aufgerufen bei der angegeben wird, welches Feld fehlerhaft ist und wie dei Fehlermeldung lautet.)
• Fortschreiben des Datensatzes (wie bisher)

Dass beim Wx_GetChgInput() das Programm beim ersten Durchlauf beendet wird und die Steuerung von der Engine übernommen wird, braucht den Programmierer nicht zu interessieren. Insbesondere da die Engine nach einer Aktion (z.B. Klick auf Sicherungs-Button) wieder übernimmt und die erfassten Werte in die definierten Variablen im RPG-Programm zurückbringt, so dass der Programmierer direkt nach Wx_GetChgInput() mit der Ein-/Ausgabe-Prüfung weitermachen kann.

Damit kann ein großer Teil der des vorhandenen Codes in Green-Screen-Bildschirm-Programmen weiterverwendet werden.

Die WOPiXX-Anwendungen, zugewiesene Bibliothekslisten, Message-Files und fertigen WOPiXX-Programme werden über die WOPiXX-Andministration registriert und können danach direkt aus dem WOPiXX-Menü aufgerufen werden.

Eine Anmerkung allerdings noch am Rande:
Es ist nichts so schnell wie eine Green-/Screen-Anwendung, insbesondere wenn mit Mehrsprachigkeit, bei der die Texte aus Message-Files ermittelt werden müssen.
Display-Files sind das einzige Tool, das Message-Texte automatisch aus Message-Files ermittelt, und dafür optimiert wurde.
Beim guten alten Green-/Screen wurden außerdem fast schon immer nur die relevanten Daten ausgetauscht. In den Web-Anwendungen kamen solche Techniken (JSF oder AJAX-Technologien) erst viel später dazu.

Birgitta

[RobertMack]

...Mehrsprachigkeit, bei der die Texte aus Message-Files ermittelt werden müssen.
Birgitta

Vor diesem Hintergrund habe ich vor etwa 20 Jahren ein Tool entwickelt welches DSPF Konstanten als MSGF-Einträge extrahiert, die DSPF Source in MSGCON oder MSGID mit Referenz auf die zuvor extrahierten Konstanten umcodiert und gleich wieder compiliert. Wer dieses Tool vor oder mit WOPiXX nutzen möchte, einfach melden...