Erste Schritte - Fenster und Klassen für interaktive Anwendungen

Schon vor vielen Jahren hat mich die Frage beschäftigt, inwieweit die Struktur transaktionsorientierter Systeme (damals ging es um CICS) mit den Prinzipien der objektorientierten Programmierung vereinbar ist. Die Antwort war: Es ist gar nicht so einfach strukturierte CICS Anwendungen zu entwickeln.

Heute haben wir HTML bzw. das HTTP Protokoll und wollen objektorientiert programmieren. Wieder stelle ich fest dass es gar nicht so einfach ist objektorientierte HTML Anwendungen zu erstellen. Im Grunde ist die Architektur von CICS sehr ähnlich der des HTTP Protokolls.

1. Der Server schickt die Beschreibung einer Seite (damals hieß es Bildschirmmaske; heute ists ein HTML Dokument) zum Client. 
2. Der Benutzer füllt Eingabefelder aus und drückt einen Button (damals wars ein physischer Knopf auf der Tastatur). 
3. Der Client schickt einen Datenstrom zum Server. 
4. Der Server startet ein Programm (damals hieß das CICS-Transaktion), das die Eingabedaten interpretiert und die nächste Seite (die nächste Maske, das nächste HTML Dokument) zum Client schickt (und alles beginnt von vorn).

Das Prinzip ist noch immer einfach und hat sich seit 1969 nicht geändert. Es ist vor allem für Systeme mit vielen Benutzern sehr effizient, wenn - anders als bei PC-Anwendungen, die auch im Hauptspeicher sitzen bleiben solange der Benutzer über seine Eingabe nachdenkt - die Verarbeitung nach dem Senden des HTML Dokuments abbricht, Speicher freigegeben wird und erst beim Einlangen des nächsten HTTP Requests (beim Klick auf einen Hyperlink oder einen Button) das Programm zur Verarbeitung gestartet wird.

Das Problem beginnt, wenn man darüber nachdenkt, dass die Definition einer Seite und die Verarbeitung der dort eingegebenen Daten logisch eng zusammen gehören. Die Interpretation von Eingabedaten hängt eben davon ab wo (in welchem Feld) sie eingegeben wurden. Und oft ist ja auch so, dass im nächsten Dialogschritt die gleiche Seite noch einmal angezeigt wird (z.B. mit neuen Daten oder zur Korrektur von Eingabefehlern).

Also will ich den Code zur Definition der Seite und zur Verarbeitung der Eingaben in einer Klasse und damit in einem File zusammenfassen. Mal ganz abgesehen von objektorientierten Grundsätzen, ist das Prinzip 1 Seite = 1 Klasse recht einfach zu verstehen und sorgt für Übersichtlichkeit in großen Systemen.

Wer Web-Anwendungen mit dem GGF Framework entwickelt, kann genau das tun.