Erste Schritte - Fenster und Dialoge

Ich denke in einer guten Anwendungsarchitektur sollte „Alles“ was zu einer Dialog-Seite gehört, in einer Klasse gekapselt sein.  Seiten in einer Web-Anwendung können wir in Anlehnung an gängige GUI Architekturen als Fenster betrachten.  Jede Fensterklasse ist für folgende Aufgaben verantwortlich:

• Öffnen des Fensters: Generierung des HTML Codes zur Darstellung des Fensters im Browser. Befüllen der variablen Felder im Fenster mit den Ausgabedaten
• Erkennen der  Benutzeraktionen im Fenster (Klick auf Buttons oder Menüs) und Aufruf von verknüpften Callback-Funktionen.
• Übernahme der Eingabedaten sofern das Fenster Eingabefelder enthält.
• Prüfung der eingegebenen Daten. Abspeicherung in einem Modell-Objekt.

Soweit so gut. Aber das ist noch nicht alles. Da Anwendungen im Allgemeinen aus mehr als einem Fenster bestehen, müssen Fenster auch Mechanismen anbieten, wie Daten von einem Fenster an ein anderes beim Öffnen übergeben werden und wie bei der Rückkehr von einem Sub-Fenster Ergebnisse übernommen und das aufrufende Fenster wiedereröffnet werden kann.

Da Web-Anwendungen immer auch Multi-User Anwendungen sind, müssen Fensterklassen auch in der Lage sein, sich in Benutzer-Sessions einzuklinken. Das heißt das Fenster muss zum Beispiel wissen, zu welchem Benutzer welche Eingabedaten gehören,  ob der Benutzer überhaupt angemeldet ist und wenn ja welche Rechte er hat.  

Es ist sinnvoll drei Arten von Fenstern zu unterscheiden:  Hauptfenster, nicht-modale Fenster und modale Fenster bzw. Dialoge. Das GGF Framework bietet jeweils eine Basisklasse dafür an.

• Hauptfenster öffnen sich beim Start einer Anwendung. Sie müssen daher die Benutzer-Session initialisieren.
• Modale Fenster bzw. Dialoge dienen zur Eingabe von Parametern zu einer Benutzeraktion. Um inkonsistente Zustände zu vermeiden, muss die Interaktion mit dem aufrufenden Fenster gesperrt werden solange der Dialog aktiv ist.
• Nicht-modale Fenster hingegen können unabhängig voneinander  du auch mehrfach geöffnet werden.

Diese Mechanismen haben sich bewährt und werden seit bald 40 Jahren in GUI’s eingesetzt. Aus diesem Grund werden diese Entwurfsmuster auch vom GGF Framework und vom ReinHTML Dialog Designer für die Entwicklung von Web-Anwendungen unterstützt. Ein einfaches Beispiel für die Anwendung der Entwurfsmuster stellt die "Contacts" Anwendung dar. 

 

 

In den weiteren Posts werde ich Schritt für Schritt  beschreiben, wie eine solche Anwendung entwickelt werden kann. 

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.

Erste Schritte - Vorbereitung

Wer interaktive Web-Anwendungen entwickeln möchte, die über ganz einfache Aufgaben wie Besucherzähler oder Formmailer hinausgehen (für diese gibt es fertige CGI Scripts) sollte sich zuerst einige Gedanken über die Architektur machen. Die Architektur, die grundlegende Struktur einer Anwendung, ist ein ganz entscheidender Faktor für Komplexität, Erweiterbarkeit und Wartbarkeit einer Anwendung.

Je größer und je langlebiger eine Anwendung werden soll, umso wichtiger ist es die richtige Architektur zu wählen. In diesem und den folgenden Beiträgen möchte ich einige Überlegungen darstellen, die der Entwicklung des ReinHTML Dialog Designers und des GGF Frameworks zugrunde liegen.

Die erste Architekturentscheidung dreht sich um die Frage, wo der Code der Web-Anwendung laufen soll. Sobald (gemeinsam genutzte) Datenbanken und/oder Sicherheit eine Rolle spielen kommt man um Server-seitige Programmierung nicht herum. Code, der am Client abläuft (Javascript) kann immer manipuliert werden und für zentrale Datenbanken ist eben ein Server nötig. Lösungen für die Anbindung der eigenen Programme an HTML Seiten am Web-Server gibt es viele. Eine Übersicht dazu findet man zum Beispiel hier. Schlussendlich geht es um die Frage:

1. soll HTML und ausführbarer Code getrennt werden (Variante CGI, Perl), 
2. soll ausführbarer Code in HTML Seiten eingebettet sein (z.B. ASP, JSP, HTML/PHP)  oder
3. soll HTML dynamisch vom ausführbaren Code ezeugt werden (z.B. PHP) ? 

Wenn man nur ein wenig Dynamik in eine ansonsten statische Webseite hineinbringen möchte, dann ist die erste Variante kein schlechter Ansatz. Der zweite Ansatz ist eine Mischform, die Vorteile beim Durchsatz bieten kann, aber wie der erste Ansatz bei einer komplexen Anwendungslogik zu komplizierten, schlecht wartberen Systemen führen kann. Wenn man aber daran denkt, hauptsächlich Anwendungen zu programmieren und HTML nur als Beschreibungssprache für die Anwendungsoberfläche sieht, ist der dritte Ansatz am flexibelsten.

Es gibt also keine "beste" Variante zur Anbindung von Server-seitigem Code. Es hängt vielmehr von den Zielsetzungen ab.

Meine Zielsetzung bei der Entwicklung des GGF Frameworks war, eine Lösung herzustellen, die sich strikt an die Prinzipien der Objektorientierung hält und besonders die Entwicklung komplexer Anwendungen unterstützt. Das läßt sich meiner Ansicht nach am besten in Variante 3 realisieren. Ein wichtiges Prinzip ist dabei die Kapselung (encapsulation) von zusammengehörigem Code. Für interaktive Anwendungen heißt das zum Beispiel, dass der gesamte Code, der ein bestimmtes Dialogfenster realisiert, in einer Klasse zusammengefasst wird.

CSS basierte Drop-Down Menüs und viel mehr

Im letzten Post habe ich angekündigt über CSS-basierte Drop-Down Menüs zu schreiben. Nun hat es etwas länger gedauert als ursprünglich gedacht. Ich habe mich entschlossen zuerst die Version 1.0 des ReinHTML Dialog Designers online zu stellen. Mit dem Tool können Anwendungsfenster und Dialogformulare interaktiv erstellt werden.

Wie angekündigt, gibt es natürlich auch eine Lösung für Drop-Down und Flyout Menüs für insgesamt 4 (!) Menü-Ebenen. Das Beste daran: Die Lösung funktioniert auch für Internet Explorer (bis zurück zum IE6) für Firefox und für Safari (getestet am iPhone 4).

Ein einfaches Menü (2 Ebenen) kann zum Beispiel mit der Demo-Anwendung ausprobiert werden.

Das wichtigste aber: In der vorliegenden Version generiert der ReinHTML Dialog Designer nun nicht nur HTML Code, sondern auch PHP Code. Das bedeutet: Sie können mit dem Tool Fenster und Dialoge interaktiv entwerfen und dann Server-seitigen PHP Code generieren.

Es entsteht pro Fenster oder Dialog eine PHP Klasse, die folgendes enthält

• PHP Code der das gesamte HTML zum Anzeigen des Fensters generiert
• Verwaltung von persistenten Modellobjekten
• Code zum Prüfen der Eingabedaten (Schutz gegen SQL Injection etc.) 
• Code zum Befüllen der Ausgabefelder mit Daten aus den Modellobjekten
• Code zum Einlesen der Modellobjekt-Daten von den Eingabedaten eines Formulars
• Template-Code für Callback-Funktionen, die die Reaktion des Systems auf aktive Benutzeroberflächen-Elemente (Links, Buttons und - siehe oben - Menüs) implementieren. 
• Funktionen zur Generierung von SQL für den Datenbank-Zugriff. 

Wie schon in der Betaversion für HTML, gilt nun auch für PHP:

• Sie können die vom ReinHTML Dialog Designer generierten PHP Klassen auf den eigenen Rechner herunterladen, dann
• manuell lokal weiterbearbeiten, ergänzen und testen und dann
• wieder hinaufladen und das Layout des Fensters oder Dialogformulars interaktiv bearbeiten,
• dann wieder herunterladen etc.

(echtes Roundtrip Engineering). Sie können sich sogar aus einer generierten HTML Version eine PHP Version erzeugen lassen und umgekehrt.

Das Ganze basiert auf einer mächtigen Anwendungsarchitektur, die von einem objektorientierten PHP Framework, dem GGF Framework, unterstützt wird. Damit lassen sich auch komplexe Web-Anwendungen zuverlässig implementieren. Der ReinHTML Dialog Designer selbst ist ein gutes Beispiel dafür. Er wurd emit dem GGF Framework und mit Hilfe früherer Versionen des Dialog Designers entwickelt.

Die Architektur von fertigen Anwendungen wird am Beispiel der Demo-Anwendung in einer ausführlichen Dokumentation (folgen Sie dem Link "Architecture" auf der GGF Framework Seite; derzeit nur auf Englisch, später werde ich auch eine Version auf Deutsch zur Verfügung stellen) erklärt. Auch der Quellcode der Demo-Anwendung steht zur Verfügung.

Ich hoffe, Sie finden das interessant. Über Ihr Feedback freue ich mich.

CSS Menüs in Web-Anwendungen

Im Internet findet man eine Reihe von Vorschlägen, wie man mit CSS auch ohne Javascript geschachtelte Menüs erzeugen kann, so wie wir sie vom Desktop kennen (vgl. http://meyerweb.com/eric/css/edge/menus/demo.html, http://csswizardry.com/2011/02/creating-a-pure-css-dropdown-menu/ oder http://nekkidblogger.com/2011/ultra-efficient-css-html-drop-menu-nekkidblogger-menu/ ). Wenn man allerdings damit eine Web-Anwendung entwickelt möchte, stößt man auf eine Reihe von Problemen.

Einige Lösungen setzen auf CSS3 Funktionen, die noch nicht von allen Browsern unterstützt werden. Es ist aber fatal, wenn das Menü nicht verwendet werden kann, weil Einträge nicht sichtbar sind.

Das Aufklappen von Dropdown- und Flyout-Menüs wird in allen Lösungen durch den "hover" Effekt ausgelöst. Dieser wird vom Mauszeiger ausgelöst. Wer keine Maus hat (Benutzer von Mobiltelefonen, Tablets) kann das Menü womöglich nicht bedienen. Dazu kommt, dass ältere Browser wie der Internet Explorer 6 hover-Effekte nur für den <a> Tag unterstützt. Man kommt dann für diesen Browser nicht ohne Javascript aus. Benutzer, die aus Sicherheitsgründen Skripte deaktiviert haben, können die Anwendung dann nicht bedienen.

Die Menüaktion wird durch einen Hyperlink ausgelöst. Das ist für statische Webseiten OK, aber in Web-Anwendungen unerwünscht, weil Benutzereingaben verloren gehen können.

Keine Menü-Lösung ohne Javascript möglich? Doch! Allerdings ist ein etwas anderer Lösungsansatz erforderlich. Darüber werde ich im nächsten Blog berichten.

Konzept für horizontales HTML Menü fertig

Wie zuletzt geschrieben, bin ich dabei ein HTML und CSS basiertes horizontales Menü mit Drop-Down Menüs und Flyout Menüs zu entwickeln, das so ähnlich aussieht, wie wir es von Desktop Anwendungen kennen. Trotz intensiven Nachforschungen im Netz konnte ich keine fertige Lösung dafür finden und habe nun eine Form entwickelt, die sowohl unter Firefox als auch im Internet-Explorer ansprechend aussieht.

Der nächste Schritt wird sein, die Lösung in den ReinHTML Dialog Designer einzubauen. Ein weiterer Baustein vom Betatest auf dem Weg zur Version 1.

Horizontale Menüs in Web-Applikationen

Wahrscheinlich sehen Web-Applikationen auch deswegen so anders aus als Desktop Applikationen, weil es manchmal gar nicht so einfach ist, gängige Benutzeroberflächen-Elemente im Browser nachzubauen.

Dieser Tage habe ich mich mit horizontalen Menüs befasst. Einfach so eine Menüzeile, wie Sie sie eben auch oben in Ihrem Web-Browser Fenster sehen.

Die erste Ebene ist noch einfach: das sind Schaltflächen vor grauem Hintergrund. Aber wenn man draufklickt, soll ein drop-down Menü erscheinen (2. Menüebene) und wenn man dort draufklickt allenfalls noch ein flyout Menü. Die sollen sich über den darunter liegenden Seiteninhalt drüber legen, ohne irgend etwas zu verschieben.

Gar nicht so einfach das mit HTML und CSS hinzubekommen. Das Web ist zwar voll mit Lösungsvorschlägen dazu, aber eine Lösung, die unter allen Umständen und auch mit älteren Browsern funktioniert und dann auch optisch so ähnlich aussieht wie wir es von unseren Desk-Top Anwendungen gewohnt sind: Das ist dann schon etwas anderes.

Es wundert mich nicht, wenn so mancher Web-Entwickler den Hut drauf haut und sich denkt: Eine Navigationsleiste am linken Rand tut es auch....