Konzept: InstantWeb

Konzept: Widgets/Oberfläche allgemein

Die Widgets sind definierte Objekte einer abstrakten Oberfläche. Sie kennen alle Elemente die sie beinhalten. Sie enthalten außerdem Informationen was sie gerade darstellen (evtl. nur einen Teil der enthaltenen Elemente) und wie sie es darstellen. Die Widgets haben in Form von Objektmethoden Schnittstellen über die alle zur Darstellung nötigen Information zu erfragen sind. Widgets beschreiben in diesem Sinne also keine konkreten Objekte einer speziellen Oberfläche( z.B. Win-Desktop oder Web) sondern vielmehr eine abstrakte Schnittstelle zum Benutzer.
Wie diese Schnittstelle konkret dargestellt wird hängt vom Darstellungsmedium ab. Die Oberflächendarstellung holt sich ausschließlich die Information von einem Widget, die es benötigt um es abzubilden.
Um Daten zu ändern werden die entsprechenden Methoden eines Widgets aufgerufen, egal für welche Oberflächenimplementierung.

Konzept: Web als Oberfläche

Der Darstellung der Widgets im Web liegen folgende Feststellungen zugrunde:

  1. Zur Darstellung/Manipulation von Daten werden nur Widgetmethoden aufgerufen (s.o.)
  2. Um fensterweite Anpassungen der Darstellung leichter umsetzen zu können, werden bestimmte Darstellungsparameter einmalig ausgelesen und später ausschließlich reproduziert (Generatorprinzip)
  3. Es soll sich um einen Thin-Client handeln

Umsetzung: Web als Oberfläche

1. Zur Darstellung/Manipulation von Daten werden nur Widgetmethoden aufgerufen

Die Darstellung/Manipulation auf verschiedenen Oberflächen erfolgt über die gleichen Methoden der Widgets.
D.h.z.B.: Aktion: Bei Selektion eines Listeneintrags, Detailinfo in einem String-Widget anzeigen:

Der Ablauf ist bei allen Oberflächen Implementierungen der selbe:

  1. Ein Ereignis der Oberfläche löst im Listenwidget das SELECT-Ereignis aus
  2. Das Listenwidget ruft eine Funktion auf die den Inhalt des Ziel-String-Widgets ändert

Zu beachten ist hierbei das die Art wie die Oberfläche das SELECT-Eregnis triggert und die folgenden Darstellungsänderungen umsetzt sehr unterschiedlich sein können:

Umsetzung Win-Desktop Umsetzung Web
Der Benutzer klickt auf einen Eintrag in der Liste
>> Unmittelbar triggert die Oberflächenbibliothek das SELECT-Ereignis, worauf sofort der Inhalt des Zielwidgets angepasst und dargestellt wird		 Problem:
  • Im Web gibt es keine Mehrspaltigen Auswahllisten
  • Im Web kann nur auf den Klick auf einen Button unmittelbar reagiert werden
Konsequenz:
Ansatz 1:Umsetzung der Liste als Table. Zusätzlich zu den dargestellten Inhalten bekommt jede Zeile einen Radiobutton und die gesamte Liste einen SELECT-Button. Wird dieser Button gedrückt wird das SELECT-Ereignis des Widgets mit dem durch den Radiobutton ausgewählten Eintrag getriggert.
Ansatz 2: Jede Zeile bekommt einen Button, der das SELECT-Ereignis der Liste mit Auswahl auf dieser Zeile auslöst.


2. Nutzung Generationsprinzip

Bei Implementierung einer bestimmten Oberfläche muss man sich in der Entwurfsphase Gedanken machen welche Informationen von einem Widget zur Darstellung auf dem Zielmedium benötigt werden.
Beispiel: Bei einer Darstellung auf einem S/W-Medium müssen keine Farbinformationen abgefragt werden.
Weiter ist die Frage zu beantworten wann die benötigten Informationen benötigt werden (immer zur Laufzeit?).
Für InstantWeb wurde festgelegt, dass ein Großteil der Informationen, die zur Form der Darstellung eines Widgets gehören, bereits vor der Laufzeit in die Repräsentation der Widgets auf der Oberfläche übertragen werden können. Dieses ist im Fall Web sogar erwünscht, da so bestimmte Parameter mit Oberflächenspezifischen Werten überschrieben werden können.
Bei InstantWeb sind das hauptsächlich Position und Größe einzelner Oberflächenelemente. Die entsprechenden Information werden durch den Generator in css-Dateien geschrieben die zur Laufzeit zur Darstellung herangezogen werden. Die dort gespeicherten Werte können von Hand überschrieben werden. Deshalb können sie zur Laufzeit von den tatsächlichen Werten eine Widgets abweichen. Daraus folgt, dass die Oberfläche auf Änderungen dieses Parameters zur Laufzeit nicht reagiert.
Z.B. wird bei Prompts sogar der Inhalt bereits vor der Laufzeit in die konkrete Oberfläche übertragen( .properties-Files). Das hat zur Folge, dass wenn ein IV-Befehl den Inhalt eines Prompts ändern würde die InstantWeboberfläche diese Änderung nicht darstellen könnte.


3. Thin-Client

Das Web als Interface soll einen absoluten Thin-Client darstellen.
Die Stärken dieses Konzepts sind

Die Nutzung des Webs als Oberfläche bringt gewisse Unterschiede zum Windows-Desktopsystem mit sich. Auf viele Ereignisse kann nicht so 'natürlich' reagiert werden. D.h., dass z.B. auf das Betreten oder verlassen eines Eingabefeldes nicht unmittelbar reagiert werden kann. Bei einer Tabelle kann der Klick auf eine Zeile gar nicht ausgewertet werden. Es gibt zwar die Möglichkeit mit JavaScript auf solche Ereignisse zu reagieren, es wurde sich aber aus den folgenden Gründen gegen den Einsatz von JavaScript entschieden:

Konsequenzen für die Entwicklung von InstantWeb

Generell muss darauf geachtet werden das sich Änderungen an Oberflächenelementen bei allen Oberflächenimplementierungen gleich auswirken. Für konkrete Implementierungen wie das Web dürfen also keine Wege (auf denen Informationen ins System fließen) die an den Widgets vorbeiführen gebaut werden . D.h. jede Änderung muss in den Widgets nachvollziehbar sein - sich also genauso auf der Desktopoberfläche abspielen. Da das Web nur eine Untermenge der Funktionen der Windowsoberflächenfunktionen bietet müssen Web-AppsWh-Module evtl. umgebaut (primitivisiert) werden. Sie müssen jedoch trotzdem auf der Desktopoberfläche genauso funktionieren ( also gleicher Wechsel von Anzeige von Information und triggern von Widgetereignissen).

Da der Einsatz von JavaScript nicht erwünscht ist können Ereignisse grundsätzlich nur nach dem Drücken eines submit-Buttons ausgelöst werden Soll also auf einen bloßen Klick ein Ereignis ausgelöst werden, muss ein entsprechender Button eingebaut werden der dieses Ereignis triggert.