Grafische Oberflächen statt 5250 Emulation

[holgerscherer]

Yepp, fehlt nur noch ein DSPSIZ(54 264 *DS9)

;-))

und die Bildschirm-Arbeitsplatzverordnung hätte gewiss was dagegen

[Fuerchau]

Ich habe ja nicht behauptet, das wopixx schlecht wäre.
Aber die Beschreibung bestätigt mich in der Behauptung (auch auf der Seite nicht sgefunden), dass es keinen Screendesigner gibt.
Somit habe ich ja wohl keinen Einfluss auf das Aussehen der Oberfläche sondern bin ggf. auf die Reihenfolge der Funktionsaufrufe angewiesen um das Layout wenigstens marginal zu beeinflussen, wie gesagt, Try and Error.
Bisher hatte für mein persönliches Verständnis jedes Tool (Java/Net, usw.) einen Oberflächendesigner.
Auch die Lösung der Mehrsprachigkeit spricht meines Erachtens nicht für dieses Design.
Da ich ja schon eine Web-Oberfläche verwende gehören die Sprachtexte eher auf diese Ebene und sind daher erheblich schneller. Hier sind dann tatsächlich andere Tools, die im ersten Schritt nur meine 5250 (z.B. per Specials, Filehandler) austauschen (auch hier meine ganz persönliche Meinung) besser geeignet. Ich kann anschließend das Layout anpassen, mit anderen Funktionen ergänzen, ohne an den RPGLE-Code heranzumüssen.
Wopixx scheint ja wohl eher die "Screens" on-the-fly zu generieren, was jeden externen Einfluss ausschließt.
Die typische und auch von modernen Anwendungen geforderte Trennung in "Frontend" und "Business Logic" sehe ich da eher nicht. Hier gilt die alte RPG-Regel: alles aus einer Hand.

[B.Hauser]

Somit habe ich ja wohl keinen Einfluss auf das Aussehen der Oberfläche

Das Aussehen der Oberfläche ist aktuell von DHTMLX bestimmt.

Die Reihenfolge in der Ein-Ausgabe-Felder oder Spalten in List-Anzeigen generiert werden bestimmt der Programmierer. Ob diese Felder z.B. nebeneinander oder in Tabellen angeordnet werden bestimmt der Programmierer lediglich ebenso wie weitere Aufbereitungs-Optionen (z.B. Muss-Feld, Combobox, Auswahllisten, Aufbereitung/DatePicker von numerischen Datum) durch entsprechende Schlüssel-Worte, die beim Prozedur-Aufruf übergeben werden können.

Wopixx scheint ja wohl eher die "Screens" on-the-fly zu generieren, was jeden externen Einfluss ausschließt.

Das ist korrekt aber auch gewollt!
Einheitliches Design für alle Bildschirme (List- und Detail-Programme - kennt man ähnlich z.B. auch von UIM).
Deshalb ist ein Screen Designer an dieser Stelle auch sinnlos.
Natürlich kann man auch zusätzlich das Default-Template das verwendet wird in einem gewissen Maß individuell erweitern.

Die typische und auch von modernen Anwendungen geforderte Trennung in "Frontend" und "Business Logic" sehe ich da eher nicht. Hier gilt die alte RPG-Regel: alles aus einer Hand.

Woher weißt Du, dass wir nicht im Untergrund genau das machen?
Im RPG-Programm wird lediglich definiert! Die Informationen werden gesammelt und zum Zeitpunkt x (Programm-Ende/Prozedur-Aufruf) aufbereitet und ausgegeben. Und zum Zeit-Punkt y (nach einer Aktion) in die RPG-Variablen zurückgegeben bzw. das nächste Programm aufgerufen.

Die alte RPG-Regel "alles aus einer Hand", simulieren wir deshalb, um den Umstieg zuerleichtern bzw. um einen großen Teil des ursprünglichen Programms beibehalten zu können.

Meine persönliche Meinung ist und bleibt, man sollte sich jedoch die Sachen anschauen, bevor man drüber diskutieren will.

Birgitta

[Fuerchau]

@Birgitta
Vielen Dank für deine vollinhaltliche Bestätigung meiner ganz persönlichen Meinung (da ich es mir nun mal gründlich angeschaut habe).

[Pikachu]

... und arbeiten dann dort dann mit schwarz/grüner Oberfläche.

Hier wäre ein Ansatzpunkt: Ändert doch mal die Farben ...

[Rainer Ross]

Hallo Watchdog,

meine Idee war es, die Geschwindigkeit des Greenscreens mit dem Charme von grafischen Anwendungen zu verbinden. Mein erstes großes Projekt war www.myhofi.com, das mit HTML5, CSS3 und Javascript gebaut ist. Die Maschine ist eine IBM i 720 mit V7R2.

Bei meiner weiteren Arbeit habe ich www.webix.com ausprobiert und war von der Schnelligkeit der Entwicklung und der guten Performance begeistert. Hier braucht man gute Javascript Kenntnisse, wie auch bei allen anderen Javascript-Frameworks. Der Vorteil ist, dass die Anwendungen auf allen Endgeräten laufen, die einen Browser haben, wie PC, Tablet und Smartphone und die Programme auf den Geräten nicht installiert werden müssen.

Beispiele: www.myhofi.com/devhtm/sidebar.htm Google Map ist eingebunden
www.myhofi.com/devhtm/charts.htm Anbindung von http://www.highcharts.com/demo

Die serverseite Programmierung kann mit allen Sprachen erfolgen, die auf IBM i laufen: RPG, C, COBOL, PHP, NodeJS, Ruby, Python und Java. Auch fremde Datenbanken, wie z.B. die Cloud-Datenbank www.cloudant.com lassen sich einfach einbinden, wie das Beispiel www.myhofi.com/devhtm/cloudant.htm zeigt.

.Net und Webentwicklungstools nutzen AJAX und JSON. Somit kann ich meine Frontendentwicklung von der Serverentwicklung abkoppeln.

Für das Design der Anwendung gibt es den Visual Designer http://designer.webix.com/quickstart - für das Design der Oberfläche den Skin Builder http://webix.com/skin-builder/

Die Entwicklung mit Webix ist ein Beispiel dafür, dass die IBM i ein hervorragender Webserver ist. Selbstverständlich kann man die Oberfläche auch mit Angular, Bootstrap, Telerik, Sencha oder was es noch so gibt entwickeln.

Was die Performance der IBM i in der Webumgebung betrifft: einfach mit www.pagespeed.de die Zeiten von myhofi.com mit anderen Websites vergleichen. Die Anwendung ist jetzt seit Juli 2014 online und hatte noch nie Probleme mit der Performance und der Skalierbarkeit.

Für die Programmentwicklung nutze ich den RDI mit den Webdeveloper-Tools.

Um die IBM i als Webserver zu betreiben, reicht der HTTP-Server. WebSphere ist für meine Arbeit nicht notwendig.

Herzliche Grüße

Rainer

[andreaspr@aon.at]

Mein erstes großes Projekt war www.myhofi.com, das mit HTML5, CSS3 und Javascript gebaut ist. Die Maschine ist eine IBM i 720 mit V7R2.

Hallo Rainer,
Ich darf dir an dieser Stelle meinen Respekt aussprechen!
Im Bereich Design und Performance können sich viele Seiten von ganz großen Firmen bei dir weit hinten anstellen!

[mk]

Hallo zusammen,

das passt ja zum Thema:


Wir zeigen auf der POW3R nach dem Motto

Modernisierung in die offene Welt mit
IBM i - PHP ZendServer - Javascript jQWidget UI Frontend

wie man heute eine Anwendung entwickeln könnte.


jQWidgets ist ein Javascript UI Framework das auf der IBM i läuft.
Weitere Infos unter http://www.jqwidgets.com/

Wir sehen uns dann in Hannover

Gruß
Michael

[Fuerchau]

Nun, an Stelle von PHP und Zend bietet sich da ja sogar als weitere Alternative Node.js nun native auf der AS/400 an. Damit könnte man nun endlich alle Nicht-RPGLer für die stabile AS/400-Welt begeistern.
Zumal man hier nicht wieder mehrere Sprachen (PHP (RPGLE als CGI?), JScript) hat sondern sich in der kompletten Java-Welt bewegt. Den Frontend mit HML5 benötigt man ja sowieseo.

[Rainer Ross]

Hallo Rainer,
Ich darf dir an dieser Stelle meinen Respekt aussprechen!
Im Bereich Design und Performance können sich viele Seiten von ganz großen Firmen bei dir weit hinten anstellen!

Hallo Andreas,

vielen Dank für die Blumen, das Projekt hat unglaublich viel Spaß gemacht und mir letztes Jahr den Innovationspreis der IBM beschert. Im Juni diesen Jahres ist die COMMON European Conference in Stockholm, hier bin ich eingeladen über mein Projekt zu sprechen http://www.cec2016.se/sessions/rainer-ross-tbd/47 Übrigens stammt das Webdesign von Ferdinand Humberg www.pixelundcode.com Das Javascript habe ich mir selber beigebracht.

Zum Thema Performance möchte ich noch anmerken, daß es für die Suchmaschinen ein wichtiges Kriterium im Ranking darstellt. Der Google Crawler ist jeden Tag auf meiner Maschine und misst jeweils die Ladezeit der Webseite, das waren in der Spitze 90.000 Requests am Tag. Eine Messung von Google ergab, dass eine halbe Sekunde längere Ladezeit der Webseite eine Umsatzeinbuße von 20% ergeben hat. Das sollte alle Betreiber von Webshops hellhörig machen lassen.

Wer mehr erfahren möchte, der kann gerne Kontakt mit mir aufnehmen. Ich unterstütze gerne.

Herzliche Grüße

Rainer

[Fuerchau]

Ich glaube auch nicht, dass sich sowas mit wopixx hätte realisieren lassen.

[Logic IT-Services]

Auch wenn ich ganz klar einen Favoriten vertrete, möchte ich doch noch ein Statement abgeben.

Fakt ist, dass mittlerweile bzgl. Oberflächen-Modernisierung ein heilloses Chaos herrscht, so dass nur noch Verunsicherung herrscht ob man sich schlussendlich richtig entscheidet. Und daran schuld ist einzig IBM. Ich möchte kein IBM Bashing betreiben, aber das muss klar gesagt so werden. So sehr man das "laissez faire" vielleicht gut heissen mag, dem ganzen Entwicklerumfeld tut das nicht gut.

Wenn ich mir das Trauerspiel um EGL anschaue, das in der IBMschen Hilflosigkeit dem RPG Volk hätte zugemutet werden sollen - eigentlich nicht schlecht und die Dojo-Widgets find ich ja auch gut, aber völlig am Ziel vorbei. Und kosten soll's ja auch nix. Doch 20K EUR für 20 Arbeitsplätze für den RDi sind auch kein Pappenstiel, dabei ist noch kein einziges Programm geschrieben worden. Immerhin gibt's nun einen grafischen Editor, basierend auf Eclipse welches es im Netz für lau zu haben ist.

Zurück zu den Technologien. In einem Blog hab ich darüber geschrieben, "Zuviele Jäger sind des Hasen Tod" und das mein ich auch so. Ich kenn die Meisten: EGL, BCD, Look, Profound, Wopixx und einige mehr. Es stellt sich doch nur die Frage, wer soll das alles unterhalten, wenn schon die GUI-Entwicklung derart verzettelt wird? Ja, man könnte sich dann schon bald die Frage nach dem Dasein der geschätzten Power i stellen, zumindest was die RPG-Entwicklung angeht.