JavaScript Behaviors

Diese Technologie hat (noch) keinen Bezug zu AJAX da sie eine allgemein verwendbare Implementierung darstellt um JavaScript Code in HTML Komponenten wieder zu verwenden. Diese Technologie hat auch keinen Bezug zu ASP.NET da sie nur die auf dem Client (Browser) verfügbaren HTML Objekte und Javascript verwendet. Sie wird aber die clientseitige Funktionalität der kommenden AJAX Controls werden und passt perfekt in ein serverseitiges Framework für Web Controls mit dem auch die Wiederverwendung von HTML Code ermöglicht wird..

Allgemein

HTML Seiten, die nur HTML verwenden, bieten nur eine beschränkte Funktionalität und erlauben es nur Informationen anzuzeigen und HTML Formulare auszufüllen. Deshalb wird oft JavaScript als Erweiterung von HTML Seiten eingesetzt um Eingaben zu prüfen, auf Klicks zu reagieren oder optische Effekte einzubringen.

Im Bereich der Wiederverwendung von einmal geschriebenen Funktionen gibt es allerdings kein Konzept außer der Möglichkeit der Include files mit ihrem flachen Programiermosdell. Das Kopieren von Sourcecode wird deshalb zum Ausgleich dieser Schwäche eingesetzt und führt oft zu nicht mehr pflegbaren oder auch sehr großen Web Seiten.

Proprietäre Behaviours

Beide verbreiteten Browser, der Internet Explorer von Microsoft als auch der Mozilla/Firefox Browser der Mozilla foundation, haben ihre eigene inkompatible Are JavaScript Funktionen und HTML auf dem Niveau von Komponenten wieder zu verwenden.

Gemeinsam ist beiden Lösungen der Vorteil gegenüber den einfachen und globalen Script Includes, dass die Funktionalität an HTML Objekte gebunden wird, über die Objekte verfügbar ist, an mehrere Objekte gebunden werden kann und Methoden, Properties und Event Handlers unterstützt.

Einfache, kompatible Behaviours

Der Aufbau einer zwischen den Browsern kompatiblen Funktionalität, die der den eingebauten Behaviours sehr ähnlich ist, ist nicht sehr schwer zu realisieren. Er besteht im Wesentlichen daraus neue Eigenschaften, spezifische Methoden und Event Handlers zu definieren, indem ein JavaScript Prototyp Objekt für jedes zu verwendende Behaviour implementiert wird. Ebenfalls wird eine Funktionalität benötigt, die diese Definition an ein HTML Objekt bindet, nachdem die Seite geladen wurde. Script Includes können verwendet werden um diese Prototypen in eine Seite einzubinden.

Ein einfaches Beispiel

Das ist ein HTML Objekt

<div id="TimerSample" style="...">click here</div>

Das ist ein einfaches Behaviour das den onclick Event abfängt und eine Update methode einbringt die den Inhalt des HTML Objektes modifiziert..

var TimerSampleBehaviour = {
  onclick: function (evt) {
    evt = evt ||window.event; // get a compatible event object
    evt.srcElement.update();
  }, // onclick

  update: function() {
    var d = new Date();
    this.innerText = d.getHours() + ':' + d.getMinutes() + ':' + d.getSeconds();
  } // update

} // TimerSampleBehaviour

Diese Behaviour Funktionalität muss an das HTML Objekt gebunden werden indem eine einfache Methode aufgerufen wird.

LoadBehaviour(document.getElementById("TimerSample"), TimerSampleBehaviour);

Die "magische" Funktionalität hinter dem Aufruf der LoadBehaviour() Methode besteht darin alle Elemente des übergebenen JavaScript Objektes durchzugehen und diese nach folgenden Regeln dem HTML Objekt zuzuweisen.

• Methoden, die mit einem "on" beginnen werden als Event Handler erkannt und werden an das HTML Objekt mit der Hilfe der spezifischen Funktionen gebunden. Es wird nur die aufsteigende (bubbling) Phase der Events unterstützt, da diese in beiden Browserfamilien implementiert ist.
• Alle anderen Methoden werden einfach als Funktionsobjekte dem HTML Objekt zugewiesen.
• Alle anderen Objekte werden dem HTML Objekt zugewiesen wenn nicht bereits eine Zuweisung für diese Eigenschaft existiert. Diese Objekte werden von allen HTML Objekten, die das gleiche Behaviour binden, gemeinsam genutzt.

Man könnte durchaus mehr erwarten, aber dies ist eine Menge an gemeinsamen Funktionalitäten die in allen unterstützten Browsern möglich ist.

Das einfache Beispiel kann auf der WebSite gefunden werden: http://www.mathertel.de/AJAXEngine/ im Bereich Samples Part 2.

Der relevante Code ist in der HTML Seite selbst und in dem cb.js Include File enthalten.

Das Schreiben von Event Handlern

Event Handler verwenden eine Namenskonvention um sie von anderen objektspezifischen Methoden zu unterscheiden indem sie mit "on" beginnen. Der Name der Funktion sollte immer in Kleinbuchstaben geschrieben sein und die Funktion erwartet genau einen Parameter für das Event Objekt.

Da der IE das Event Objekt nicht dem Event Handler als Parameter übergibt benötigt man immer eine erste Zeile an Code um ein kompatibles Event Objekt zu bekommen:

evt = evt || window.event; // get a compatible event object

Das angeclickte HTML Objekt ist über die srcElement Eigenschaft des Event Objektes verfügbar.

Das ist eine im Mozilla/Firefox nicht eingebaute Eigenschaft die erst durch einen spezifischen Patch der ebenfalls im cb.js - neben einigen anderen Patches – vorhanden ist.

Ich denke, dass es eine gute Idee ist nicht allzu viel Code in diesen Handlern zu implementieren sondern recht zügig eine andere Methode aufzurufen. Da Event Handler im Gegensatz zu anderen Methoden immer ein Event Objekt erwarten können sie schlecht durch einen Aufruf aus anderen Methoden heraus wieder verwendet werden.

Das Schreiben von Methoden

Das Schreiben einer Methode für ein Behaviour ist in etwa so einfach wie das Schrieben von kompatiblem JavaScript.

Eigenschaften und Attribute sowie weitere an das HTML Objekt gebundene Methoden sind über die "this" Objektreferenz verfügbar, die auf das HTML Objekt zeigt. Die Methoden des JavaScript Prototypen dürfen nicht direkt aufgerufen werden. Sie sind alle über das "this" Objekt erreichbar.

Um das Schreiben von kompatiblen JavaScript Methoden zu erleichtern gibt es im Include File cb.js einige Erweiterungen. Der Mozilla/Firefox Browser hat ein sehr mächtiges Erweiterungskonzept das es sehr einfach erlaubt für die eingebauten Objekte neuen Eigenschaften zu definieren und Ihre Verwendung zu kontrollieren. Der IE ist in diesem Bereich noch sehr rückständig und so wird diese Erweiterungen verwendet um IE spezifische Eigenschaften auf die Mozilla/Firefox Plattform zu bringen. Details dazu kann man den Kommentaren des gemeinsamen Include Files cb.js entnehmen.

Das Definieren von Default-Eigenschaften

Neue Eigenschaften des Behaviour Objektes müssen nicht definiert werden; man kann sie einfach verwenden allerdings immer über "this". Die Eigenschaften die man zur Parametrierung für die Steuerung von Aspekten der Funktionalität verwendet können auf 2 Arten definiert werden:

• Bei dem HTML Objekt kann ein Attribut gesetzt werden
• Auf dem JavaScript Prototyp kann eine Eigenschaft auf einen initalen Wert gesetzt werden der verwendet wird, wenn noch kein Wert auf dem HTML Objekt definiert wurde.

Wenn man komplexe Objekte (Arrays, Strukturen) innerhalb des Javascript Objektes definiert werden muss man darauf achten, dass diese Objekte von allen HTMO Objekten aus verwendet werden die diesen Prototypen verwenden. Wenn man individuelle komplexe Objekte benötigt ist es besser diese in der init() Methode erst anzulegen.

Die init Methode

Es ist möglich eine Methode mit dem Namen "init" in den JavaScript Prototypen zu definieren, wenn spezielle Dinge benötigt werden nachdem alle Methoden, Event Handler und Properties an das HTML Objekt gebunden wurden. Diese Methode wird automatisch durch LoadBehaviour() aufgerufen.

Wenn die "init" Methode aufgerufen wird ist es nicht garantiert, dass die ganze Seite bereits geladen ist oder dass andere Behaviour Objekte bereits angebunden wurden. Wenn dieser Zeitpunkt benötigt wird ist es notwendig einen speziellen Handler an das onload event der Seite anzubinden.

Links

The Mozilla/Firefox behaviours: http://www.mozilla.org/projects/xbl/xbl.html

The IE behaviours: http://msdn.microsoft.com/workshop/components/htc/reference/htcref.asp

Search for behaviours using Google: http://www.google.com/search?q=htc+filetype%3Ahtc

posted by MatHertel @ 8/22/2005,   0 comments links to this post  

Aspekte der Applikation

Die bis jetzt von mir veröffentlichten Beispiele zur Verwendung von AJAX hatten das Ziel spezielle Aspekte des technischen Designs und der Implementierung aufzuzeigen. Sie entsprechen der "Bottom-Up" Methode und beschäftigen sich mit den Basiskomponenten JavaScript, XMLHTTP, XML und der asynchronen Verarbeitung von denen die AJAX Architektur ihren Namen ableitet.

Das zu erreichende Ziel ist allerdings nicht nur technologische Spielereien sondern eine komplette Anwendung neu zu realisieren oder eine vorhandene Applikation mit der Hilfe der AJAX Engine zu verbessern und zu modernisieren.

Die Verwendung von AJAX setzt glücklicherweise keine bestimmte prinzipielle Vorgehensweise in einer Web Applikation voraus sondern setzt auf der Ebene der Komponenten einer Web Applikation an.

Integration von AJAX Komponenten

In einigen Fällen lässt sich eine auf AJAX basierende Funktionalität in eine bestehende Web Applikation integrieren um das Problem einer Komponente besser zu lösen.

Das LookUp Beispiel kann z.B. in einer herkömmlichen Web Form verwendet werden und das Validieren von Inhalten eines HTML Formulars im Hintergrund kann vor einem regulären Abschicken des Formulars den Anwender unterstützen.

Das auf dem Client zusätzlich zu ladende JavaScript ist mit 18 kByte für die AJAX Engine und dem Code für die das Handling der Auswahlliste nicht sehr groß. Es hilft aber dabei, ein Vielfaches dieser Größe einzusparen, da der Datenanteil nicht komplett auf den Client geladen werden muss und der Neuaufbau der Seiten mehrfach entfällt. AJAX basierte Komponenten entwickeln besonders damit die größten Vorteile und es ist wichtig leicht integrierbare Komponenten zu haben.

AJAX Controls

Beim Aufbau von neuen Web Applikationen ist es ebenfalls von Vorteil, wenn die Realisierung nicht in jeder individuellen Seite vorgenommen auf einem sehr detaillierten Niveau vorgenommen werden muss sondern vorgefertigte Komponenten gleichberechtigt neben regulären HTML Objekten zum Aufbau der Seite verwendet werden können.

Um eine hohe Wiederverwendbarkeit von solchen Komponenten zu erreichen werden diese außerhalb der Seiten realisiert und durch entsprechende Parameter bzw. Attribute in der Seite für ihren konkreten Einsatz parametriert.

HTML wird zur Beschreibung des Aussehens der Controls und JavaScript zur Implementierung des Verhaltens verwendet. Die Kopplung von JavaScript Methoden an die HTML Objekte wird vom Internet Explorer (*.htc) und vom Mozilla/Firefox (*.xbl) jeweils angeboten, allerdings in sehr unterschiedlichen Implementierungen die zu einer doppelten Implementierung führen würden. Ich verwende deshalb eine einfache aber kompatible Verbindung.

ASP.NET und AJAX Controls

Meine Wahl der Realisierung einer Sammlung von AJAX fähigen Controls fällt auf ASP.NET und die darin vorhandenen User Controls. Diese sind leicht zu erstellen und anzupassen. Sie bieten im Vergleich zu WebControls, die als Klassen zu realisieren sind bereits genug Möglichkeiten. Außerdem sollen sich mit ASP.NET 2.0 User Controls auch vollständig kompilieren lassen.

Der Aufbau eines kompletten neuen Frameworks halte ich für nicht sinnvoll, denn es gibt bereits einige sehr brauchbare Frameworks, die es erlauben komponentenbasiert Webanwendungen zu realisieren.

Da die zu realisierenden Controls sind in der Substanz in HTML und JavaScript zu realisieren sind nutzen sie die auf dem Server verfügbaren ASP.NET Funktionalitäten nicht wirklich. Lediglich das Montieren des HTML Codes einer Seite aus Komponenten wird benötigt und dies kann auch auf Tag- Bibliotheken anderer Umgebungen übertragen werden.

Der Vorteil von ASP.NET liegt daneben in der einfachen Realisierung von WebServices.

posted by MatHertel @ 8/20/2005,   2 comments links to this post  

Model View Controller (MVC) Pattern

Für Software Architekten sind prinzipielle Überlegungen zum Aufbau und zur Schichtung der Komponenten einer Applikation wichtig denn sie erlauben es den notwendigen Abstand zu einer konkreten Implementierung zu erzeugen um grundsätzliche Prinzipien zu erkennen und unnötige konkrete Abweichungen aufzudecken.

Manchmal führen sie auch zu weit bis in zu religiösen Diskussionen und heiligen Prinzipien.

In diesen Bereich fällt auch das so genannte Model-View-Controller (MVC) Pattern das auf einer für Patterns sehr hohen Ebene eine Funktions- und Aufgabenverteilung im Bereich der Modellierung von oberflächennahen Objekten beschreibt. Es wurden darüber bereits Bücher geschrieben und auch das im Web verfügbare Material ist ausführlich.

Da mit AJAX Applikationen eine für viele weborientierte Entwickler eine neue Art der Modellierung von Applikationen entsteht habe ich hier einige der Aspekte meiner Sichtweise der Dinge zusammengetragen. Meine Herangehensweise ist dabei die existierende Realisierung meiner AJAX Engine zu analysieren und nicht eine ideale MVC Architektur bewusst herbeizuführen.

Die Definition(en) von MVC

Quellen für unterschiedliche Definitionen des Model View Controller Patterns gibt es in großen Mengen (google it!). Ich halte mich vorerst an die Kurzform der aktuellen Definition von Wikepedia: http://en.wikipedia.org/wiki/Model-view-controller.

• Das Model ist die anwendungsspezifische Repräsentation der Information (Daten und Funktionen) einer Anwendung.
• Der View überträgt das Model in eine Form, typischerweise einer Benutzeroberfläche, mit der eine Interaktion möglich wird.
• Der Controller reagiert auf Ereignisse, typischerweise Aktionen des Benutzers, und veranlasst Änderungen am Modell und am View.

Model

Der Model Anteil der Architektur ist ziemlich einfach in den WebServices zu entdecken. Hier sollte man alle funktionalen Aspekte auffinden können. Natürlich gibt es auch funktionale Aspekte im Bereich der Benutzeroberfläche aber dieser Code beschäftigt sich hauptsächlich um eine angenehme Art der Bedienung und um Themen der Präsentation.

Aufgrund der Rolle, die dieser Code in der Gesamtarchitektur übernimmt, können einige typischen Aspekte des Models erkannt werden, die bereits aus der SOA Architektur bekannt sind. Hier einige Stichworte:

• unabhängig von HTML Objekten
• keine kultur- und sprachspezifischen Eigenschaften
• Manipulation und Speicherung von Daten
• zustandslos
• Prüfung und Sicherung aller Parameter
• verlässliche Algorithmen und Funktionalitäten

View

Auch der View Anteil ist in der Realisierung der Oberfläche durch HTML Objekte und einigen ergänzenden JavaScript Methoden lokalisierbar.

Durch die Grundfunktionalität der HTML Objekte wie z.B. das Verändern von Werten wird vieles bereits abgedeckt aber auch weite Bereiche der JavaScript Implementierung der Seiten meiner Beispiele, z.B. die Anzeige von LookUp Listen oder der Aufbau der Grafiken gehört zum View.

• UI Events
• Aktive Elementen (Eingabefelder)
• Layout Elemente und schmückendes Beiwerk
• Konvertierungen zwischen Zahlen- und Datumsobjekte in Strings
• Funktionen zur Unterstützung der Bearbeitung

Controller

Wo ist in einer AJAX Anwendung der Controller und wie funktioniert er?

Eine einfache Antwort liegt nahe: Die AJAX Engine. Neben den WebServices und dem HTML bleiben ja nur die JavaScript Includes und die implementierten Zeilen um diese zu steuern. Die Proxies für die WebServices kann man sicher der Netzwerk-Infrastruktur zuschreiben.

Page-Controller

Bei dem Vergleich von traditionellen ASP.NET Web Forms mit dem MVC Pattern wird immer wieder der Begriff des Page-Controllers verwendet. Im direkten Vergleich zu Struts fällt bei ASP.NET nämlich schnell auf, dass die serverseitige Implementierung jeweils nur die Objekte einer Seite kennen und die Zusammenarbeit dieser lokalen Objekte implementiert.

Die Verbindungen und Übergänge zwischen den Seiten wird mit ASP.NET 1.1 nicht wirklich unterstützt wird. Man verwendet Hyperlinks im HTML oder Redirect Anweisungen im Server und hat manche Probleme zu lösen wenn Informationen einer Seite auf eine andere Seite weitergegeben werden müssen. Mit ASP.NET 2.0 ist es möglich 2 Seiten im Server die aktuelle und nie nächste anzuzeigende Seite gleichzeitig aufzubauen und damit die Übergabe der Daten recht einfach zu implementieren. Eine Lösung für die Kontrolle des globalen Ablaufs einer Web-Applikation ist dies allerdings nicht.

Struts hingegen vermischt beide Aspekte, was zu sehr großen und komplexen struts-config.xml Konfigurationsdateien führen kann.

Beide Ansätze, Web-Applikationen zu realisieren, sind in http://msdn.microsoft.com/library/en-us/dnaspp/html/ASPNet-ASPNet-J2EE-Struts.asp bzw. in http://struts.apache.org/userGuide/building_controller.html im Hinblick auf das MVC Pattern recht gut beschrieben.

Bei der Realisierung von AJAX Applikationen wird dagegen der Controller Anteil der Applikation auf den Client verlagert. Wie bei ASP.NET kontrolliert er nur die Aktivitäten einer Seite denn beim Navigieren auf andere Seiten werden alle Zustände und Konfigurationen auf dem Client komplett verworfen und neue aufgebaut. Aus diesem Grund bestehen einige AJAX Anwendungen nur aus einer einzigen und komplexen Seite oder aus framesets.

Mir drängt sich hier der Vergleich mit den 2-tier Applikationen der 90-er Jahre auf, denn auch hier was der Controller immer im (Fat-)Client realisiert und der Server stellte Daten und Methoden (typischerweise SQL Connections und Stored Procedures) zur Verfügung.

posted by MatHertel @ 8/11/2005,   1 comments links to this post