Einchecken
Kommentare

Zusammenbau der DIV-Inhalte auf der Serverseite
Die vom DataRequestor-Objekt abgesendeten Requests werden auf der Serverseite von einer Engine verarbeitet. Diese Engine erhält vom Request-Objekt mehrere

Zusammenbau der DIV-Inhalte auf der Serverseite

Die vom DataRequestor-Objekt abgesendeten Requests werden auf der Serverseite von einer Engine verarbeitet. Diese Engine erhält vom Request-Objekt mehrere Parameter. Für dieses Beispiel wichtig sind die Parameter Mode und Key. Diese werden dem XMLHttp-Objekt auf der Clientseite über die Methode req.addArg() hinzugefügt. Der Wert des Parameters Key wird zerlegt und die zugehörige Aufgabe berechnet.  Die Businesslogik weiß anhand des Wertes des  Mode-Parameters, um welche Art von Datentransport es sich handelt. Für unser Beispiel ist der Wert des (hier vereinfachten) Mode-Parameters getDataMonth. Der übergebene DataID-Parameter ist ein die Anforderung spezifizierender Schlüssel. Für die Zeile, die den Preis der Rate EZ_BP (EUR) anzeigt, sieht das so aus: Der Schlüssel oder die ID ist ‘mnth200702room55pr220‘. Die Businesslogik benötigt folgende Daten:

  • Datum für den Februar 2007: ,mnth 200702room55pr220′
  • startDatum = 01.02.2007, endDatum = 28.02.2007;
  • ID des Zimmers: ,mnth200702room 55pr220′
  • objHotelRoom.RoomID = 55;
  • ID der Rate: ,mnth200702room55pr 220′ (pr bedeutet public rate und meint die in Abb. 1 als „Allg. Raten“ angezeigten Raten)
  • objRate.RateID = 220, objRate. RateType = PublicRate

Dies ist die Information, die der Business­logik genügt, um die entsprechenden Preisdaten für einen Monat zu ermitteln. Schließlich werden die HTML-Tags mit den Daten zum kompletten Monatsblock zusammengebaut. Das hat den Vorteil, dass der Client lediglich den gesamten Block in den DOM-Baum einhängen muss, sobald er ihn vom Server erhalten hat. Im Grunde hätte es ausgereicht, die erforderlichen Rohdaten (hier die Preise) zum Client zu senden. Anschließend könnte dieser selbst den Block zusammenbauen und in den DOM-Baum einhängen. An dieser Stelle ist die Trennung zwischen Model und View vielleicht etwas durchsichtig. Es erschien jedoch als wenig vorteilhaft, den Client mithilfe spezieller Skripte einzelne HTML-Primitive selbst aufbauen zu lassen. Diese Aufgabe ließ sich sehr einfach auf Serverseite erledigen. Da es sich nicht um komplizierte HTML-Konstrukte handelt, sondern lediglich um einzelne Tabellenelemente, erschien uns diese Vorgehensweise auch im Sinne einer beschleunigten Darstellung als gerechtfertigt. Im anderen Falle hätte man die vollständigen Tabellen pro Monat bereits im Speicher des Clients haben und anschließend über aufwändige DOM-Manipulationen pro Tag mit den Rohdaten füllen müssen. Jeder einzelne Wert erhält beim Zusammenbau der HTML-Tabelle eine eindeutige ID, ähnlich der ID der Anforderung in dem Beispiel. Diese ID ist wichtig für das Speichern von Änderungen, die in einzelnen Zellen vorgenommen werden. Nachdem der komplette Block mit Daten und IDs erstellt wurde, geht es dann zurück zum Client. Dieser, also die AJAX-Engine, erhält dann per Callback-Methode das HTML-Paket und entscheidet weiter, was damit geschieht.

Zurück auf der Clientseite

Das XMLHttp-Objekt besitzt das Property onreadystatechange, das mit einem Funktionsobjekt belegt wird self.callback (Listing 2). Wenn sich der Bearbeitungszustand ändert, wird das XMLHttp-Objekt über die Änderung des ReadyStates informiert und die callback-Methode aufgerufen. ReadyState kann verschiedene Zustände annehmen. Für uns interessant ist der im XMLHttp-Objekt definierte Wert 4 (=completed), der die vollständige Übertragung des Codes anzeigt. Wie in Listing 1 dargestellt, wurde die ID des DIV-Blocks gespeichert, der den gelieferten Code erhalten soll: req.setObjToReplace(objID); Über die Methode objDIV = self.getObjToReplace(); wird der DIV-Block für die weitere Verarbeitung gespeichert. Das XMLHttp-Objekt enthält in der Variablen responseText den Inhalt des empfangenen Response-Objekts. In unserem Beispiel ist das eine Tabelle mit einer Zeile, die die Preise der einzelnen Tage des Monats Februar im Jahr 2007 enthält. Dieser HTML-Absatz wird als inner HTML des entsprechenden DIV-Blocks eingehängt.

Abb. 2: Aktivitätsdiagramm Client-Server-Kommunikation

In Abbildung 2 ist der komplette Kommunikationsablauf vom Mausklick des Users, über die AJAX-Engine des Clients, hin zum Server und zur Businesslogik samt Rückweg noch einmal schematisch dargestellt.

Austausch von Daten

Der Anwender bekommt nicht nur Daten zur Ansicht, sondern auch zur Bearbeitung. Neben Änderungsmöglichkeiten von Kontingenten, Preisen und Verpflegungsarten bietet das System dem Benutzer z.B. die Möglichkeit, Messezeiträume einzupflegen.

Messezeiträume sind in der Monatsansicht durch einen gelben Hintergrund gekennzeichnet. Diese können über eine Dropdown-Liste eingestellt werden. Die Dropdown-Liste enthält als Werte Stornierungsfristen, d. h. Zeitpunkte, bis zu denen die Reservierung storniert werden kann. Zu Beginn des Lebenszyklus einer Rate existieren noch keine Messezeiträume. Diese können entweder über einen Assistenten (wird hier nicht behandelt) oder über die Monatsansicht eingestellt werden. Die Umstellung zur Messe ist auf  Tagesebene möglich. Dafür wählt der Benutzer in dem Feld „Messe/Saison (Storno­bedingungen)“ einen Wert für die Frist aus. Da für die Messe andere Bedingungen (Preise, Verpflegungsart, Minimum (Tage) des Aufenthaltes) seitens des Hotels gewünscht sind, stellt die Businesslogik eine eigene Messerate mit eigenen Ratendetails zur Verfügung. Dies hat zur Folge, dass für einen Tag, der auf „Messe“ umgestellt wird, alle relevanten Daten der betroffenen Rate erneuert werden müssen (es wird also nicht nur der Preis ausgetauscht).

Wie läuft dies nun innerhalb der AJAX-Engine ab (Abb. 2). Diese erhält per onchange-Event der DropDown-Liste den Hinweis, dass der „Messe/Saison (Stornob.)“-Eintrag auf einen Wert > 0 gesetzt wurde. Dies ist der Indikator für einen Messezeitraum. Es werden die Zellen-IDs für diejenigen Tage, die auf Messe umgestellt werden sollen, ermittelt. Anschließend wird erneut ein DataRequestor-Objekt erzeugt, das die entsprechenden Daten vom Server anfordert. Dies geschieht wiederum mit der vom DataRequestor-Objekt bereitgestellten Methode open(). Als mode-Parameter wird dieses Mal getDataFair benutzt. Dadurch wird dem Server mitgeteilt, dass es sich um den Austausch von Raten-Daten handelt, also um den Austausch einzelner Zellen. Der Parameter DataID enthält mehrere IDs, die die betroffenen Zellen der eingeblendeten Blöcke referenzieren. Auf der Serverseite wird über die Businesslogik anhand einer Referenz-ID die aktuelle Rate ermittelt. Eine von dieser Rate referenzierte Messerate liefert entsprechende (vordefinierte) Messewerte für die auszutauschenden Zellen. Das Berechnen der entsprechenden Messepreise ist nicht trivial und wird einzig von der Businesslogik beherrscht. Auf diese Weise muss der Client nur ihm gelieferte Preise anzeigen, ohne selbstständig eine Logik zu verfolgen, in der er dann zwischen einzelnen Messe- und Nicht-Messeraten unterscheiden müsste. Diese Arbeit wird auf den Server ausgelagert, der als einziger weiß, welche Messepreise aktuell gelten. Die Daten werden von diesem in ein HTML-Konstrukt gepackt und zum Client zurückgesendet. Dort wird das Konstrukt von der AJAX-Engine genommen und entsprechend der zuvor ermittelten IDs in den DOM-Baum eingehängt.

Abschließende Betrachtungen

Im vorliegenden Artikel wurde gezeigt, wie wir AJAX mithilfe einiger weniger Codezeilen und ohne Verwendung eines großen Frameworks verwendet haben, um einen dynamischen Web Client zu schaffen, der den Anforderungen aus der Hotellerie genügt. Den Kern der Anwendung bildet das DataRequestor-Objekt, das einen Wrapper um das XMLHttp-Objekt darstellt. Mit diesem Objekt ist es vergleichsweise einfach, Daten mit der Businesslogik auszutauschen, ohne die Seite neu zu laden. Der hier gezeigte Ansatz des Anforderns einzelner HTML-Fragmente ist pragmatisch und ohne großen Aufwand aufseiten des Clients realisierbar.

Matthias Donaubauer und Stefan Roth arbeiten beide für die hotel.de AG. M. Donaubauer implementierte die in myRES 2006 verwendeten AJAX-Verfahren. S. Roth beschäftigt sich seit Längerem mit XML und Web Services und implementierte u.a. die Businesslogik von myRES 2006.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -