dschroeder
06-05-13, 17:44
Hallo liebe Forumsteilnehmer,
ich komme heute mal nicht mit einer Frage zu euch, sondern ich möchte mal einen kurzen Zwischenbericht darüber abgeben, wie sich bei uns die Einführung einer browserbasierten Anwendungsgestaltung auf der iSeries entwickelt hat. Ich möchte explizit betonen, dass ich hier keine Werbung für das bei uns eingesetzte Produkt machen will und dass mich auch kein Lieferant gebeten hat, hier etwas zu schreiben! Ich bin aber ziemlich sicher, dass sich viele für das Thema interessieren. Deshalb hier unsere bisherigen Erfahrungen in Kurzform:
Wir haben vor einem Jahr die Software ProfoundUI gekauft. Damit lassen sich browserbasierte Oberflächen mit RPGLE programmieren. Zusätzlich haben wir "Genie" (ebenfalls von Profound) gekauft. Das ist quasi eine browserbasierte Emulation. Wenn man Genie einsetzt, kann man normale Green Screen Masken und neue ProfoundUI Masken problemlos mischen.
Der Grundeinstieg ist wirklich sehr einfach. Im Prinzip arbeitet man in RPGLE weiterhin so, wie man es mit DDS-Bildschirmdateien auch tun würde. Nur werden die Masken nicht im SDA entworfen, sondern mit dem sogenannten Visual Designer. Der Designer erzeugt letztendlich eine DDS-DSPF. Das RPG-Programm verarbeitet dann diese DSPF. Der Sourcecode der DDS ist allerdings nicht sinnvoll zu lesen und kann natürlich auch nicht mit SDA sinnvoll interpretiert werden. Statt SDA muss man eben immer den Visual Designer bemühen, wenn man eine DSPF wieder editieren will.
Ich muss wirklich sagen, dass der Zugang zum Visual Designer echt problemlos war. Wir haben kurz nach dem Kauf ein kleines Projekt (ein paar Wochen Entwicklung) durchgezogen. Die Software läuft sehr stabil. Genauso wie wir es von RPG und Green Screen gewohnt sind. Die Entwicklung hat prinzipiell nicht länger gedauert, als wenn wir das ganze im Green Screen gemacht hätten. Ich sage "prinzipiell", weil wir uns natürlich für die neue Art der Darstellung erstmal eine Reihe von Tools erstellt haben. Das haben wir vor Jahren natürlich auch für den Green Screen gemacht. (Z.B. ein Tool, mit dem man einen Text per Window anzeigen kann). Wir hätten das eigentlich nicht machen müssen. Man kann aus einer Profound-Maske einfach ein normales Green Screen Programm aufrufen. Funktioniert einwandfrei. Allerdings ist es designmäßig doch ein ziemlicher Bruch, wenn man ein natives grafisches Programm mit einem Window aus DDS beglückt.
Also alles super?
Jein. Anfangs hatte das Produkt doch zahlreiche Kinderkrankheiten, die zwar nie gravierend waren, aber die lästig waren. Jetzt (ca. 30 Updates später) ist es eine ziemlich runde Sache. Die Updates, die in letzter Zeit geliefert werden, bringen hauptsächlich neue Funktionalität anstatt nur Fehler zu fixen.
Die eigentlichen Probleme, die wir mit ProfoundUI haben, liegen nicht direkt im Produkt begründet. Wir haben inzwischen erkannt, dass es nicht trivial ist, einfach einen visuellen Designer zu nehmen und hübsche Masken zu malen. Die Arbeit, die man sich vor Jahren im Greenscreen Bereich gemacht hat (wie sehen Masken standardmäßig aus, wie kann ein Anwender das am besten bedienen, ...) muss man sich noch einmal machen. Man kann die bisherigen Green Screen Bedienkonzepte nicht einfach auf eine grafische Maske übertragen. Z.B. haben wir bisher viel mit programmgesteuerten Subfiles gearbeitet. In einer grafischen Oberfläche erwartet man aber, dass man z.B. die Sortierung der Spalten einfach durch Doppelklick auf den Spaltenkopf ändern kann. Das kann ProfoundUI zwar automatisch. Aber dazu muss man die Subfile vorher komplett füllen. Also eine systemgesteuerte Subfile verwenden.
Ein weiteres Problem ist die Browserdarstellung. Ich hätte es vorher nicht für möglich gehalten, dass jeder Browser soviele Eigenarten besitzt. Standardisierung ist für die Browserhersteller anscheinend ein Fremdwort. Eine Maske, die in einem Browser gut aussieht, sieht in einem anderen ganz anders aus. Da muss man echt Abstriche in der Erwartung machen. Ich würde sagen, man beschreibt seine Maske nicht mit Befehlen, sondern man macht dem Browser eher unverbindliche Vorschläge, wie man sich das Aussehen vorstellt. Was der Browser dann daraus macht, weiß vorher keiner! Nein, im Ernst: Es geht schon, aber man muss sich gedanklich davon lösen, dass eine Maske in jedem Browser exakt gleich aussieht. Wir haben auch eine Java-Entwicklungsmannschaft für die Web-Entwicklung. Die kämpfen den ganzen Tag mir den unterschiedlichen Browsern. Für die iSeries haben wir das pragmatisch gelöst: Da wir nur interne Anwendungen schreiben, haben wir uns konzernweit auf einen Browser festgelegt. Wir testen nur in diesem Browser und fertig.
Fortsetzung folgt gleich.
Dieter
ich komme heute mal nicht mit einer Frage zu euch, sondern ich möchte mal einen kurzen Zwischenbericht darüber abgeben, wie sich bei uns die Einführung einer browserbasierten Anwendungsgestaltung auf der iSeries entwickelt hat. Ich möchte explizit betonen, dass ich hier keine Werbung für das bei uns eingesetzte Produkt machen will und dass mich auch kein Lieferant gebeten hat, hier etwas zu schreiben! Ich bin aber ziemlich sicher, dass sich viele für das Thema interessieren. Deshalb hier unsere bisherigen Erfahrungen in Kurzform:
Wir haben vor einem Jahr die Software ProfoundUI gekauft. Damit lassen sich browserbasierte Oberflächen mit RPGLE programmieren. Zusätzlich haben wir "Genie" (ebenfalls von Profound) gekauft. Das ist quasi eine browserbasierte Emulation. Wenn man Genie einsetzt, kann man normale Green Screen Masken und neue ProfoundUI Masken problemlos mischen.
Der Grundeinstieg ist wirklich sehr einfach. Im Prinzip arbeitet man in RPGLE weiterhin so, wie man es mit DDS-Bildschirmdateien auch tun würde. Nur werden die Masken nicht im SDA entworfen, sondern mit dem sogenannten Visual Designer. Der Designer erzeugt letztendlich eine DDS-DSPF. Das RPG-Programm verarbeitet dann diese DSPF. Der Sourcecode der DDS ist allerdings nicht sinnvoll zu lesen und kann natürlich auch nicht mit SDA sinnvoll interpretiert werden. Statt SDA muss man eben immer den Visual Designer bemühen, wenn man eine DSPF wieder editieren will.
Ich muss wirklich sagen, dass der Zugang zum Visual Designer echt problemlos war. Wir haben kurz nach dem Kauf ein kleines Projekt (ein paar Wochen Entwicklung) durchgezogen. Die Software läuft sehr stabil. Genauso wie wir es von RPG und Green Screen gewohnt sind. Die Entwicklung hat prinzipiell nicht länger gedauert, als wenn wir das ganze im Green Screen gemacht hätten. Ich sage "prinzipiell", weil wir uns natürlich für die neue Art der Darstellung erstmal eine Reihe von Tools erstellt haben. Das haben wir vor Jahren natürlich auch für den Green Screen gemacht. (Z.B. ein Tool, mit dem man einen Text per Window anzeigen kann). Wir hätten das eigentlich nicht machen müssen. Man kann aus einer Profound-Maske einfach ein normales Green Screen Programm aufrufen. Funktioniert einwandfrei. Allerdings ist es designmäßig doch ein ziemlicher Bruch, wenn man ein natives grafisches Programm mit einem Window aus DDS beglückt.
Also alles super?
Jein. Anfangs hatte das Produkt doch zahlreiche Kinderkrankheiten, die zwar nie gravierend waren, aber die lästig waren. Jetzt (ca. 30 Updates später) ist es eine ziemlich runde Sache. Die Updates, die in letzter Zeit geliefert werden, bringen hauptsächlich neue Funktionalität anstatt nur Fehler zu fixen.
Die eigentlichen Probleme, die wir mit ProfoundUI haben, liegen nicht direkt im Produkt begründet. Wir haben inzwischen erkannt, dass es nicht trivial ist, einfach einen visuellen Designer zu nehmen und hübsche Masken zu malen. Die Arbeit, die man sich vor Jahren im Greenscreen Bereich gemacht hat (wie sehen Masken standardmäßig aus, wie kann ein Anwender das am besten bedienen, ...) muss man sich noch einmal machen. Man kann die bisherigen Green Screen Bedienkonzepte nicht einfach auf eine grafische Maske übertragen. Z.B. haben wir bisher viel mit programmgesteuerten Subfiles gearbeitet. In einer grafischen Oberfläche erwartet man aber, dass man z.B. die Sortierung der Spalten einfach durch Doppelklick auf den Spaltenkopf ändern kann. Das kann ProfoundUI zwar automatisch. Aber dazu muss man die Subfile vorher komplett füllen. Also eine systemgesteuerte Subfile verwenden.
Ein weiteres Problem ist die Browserdarstellung. Ich hätte es vorher nicht für möglich gehalten, dass jeder Browser soviele Eigenarten besitzt. Standardisierung ist für die Browserhersteller anscheinend ein Fremdwort. Eine Maske, die in einem Browser gut aussieht, sieht in einem anderen ganz anders aus. Da muss man echt Abstriche in der Erwartung machen. Ich würde sagen, man beschreibt seine Maske nicht mit Befehlen, sondern man macht dem Browser eher unverbindliche Vorschläge, wie man sich das Aussehen vorstellt. Was der Browser dann daraus macht, weiß vorher keiner! Nein, im Ernst: Es geht schon, aber man muss sich gedanklich davon lösen, dass eine Maske in jedem Browser exakt gleich aussieht. Wir haben auch eine Java-Entwicklungsmannschaft für die Web-Entwicklung. Die kämpfen den ganzen Tag mir den unterschiedlichen Browsern. Für die iSeries haben wir das pragmatisch gelöst: Da wir nur interne Anwendungen schreiben, haben wir uns konzernweit auf einen Browser festgelegt. Wir testen nur in diesem Browser und fertig.
Fortsetzung folgt gleich.
Dieter