Unter http://www.ol-commerce.de/olcommerceshop/ajax/index.php ist die erste Test-Version eines vollständig AJAX-basierten Shop-Systems (PHP basierend) online.

olCommerce ist ein Ableger von xtCommerce 2, was wiederum ein Ableger von osCommerce ist.

AJAX-fähig ist olCommerce überhaupt nur deshalb, weil es (im Gegensatz zu osCommerce, das den HTML-Code “on-the-fly” überall im Programm generiert und per PHP-“echo” ausgibt) die Rendering-Engine “Smarty” verwendet, so dass man an zentraler Stellen weiss, für welche Bildschirmbereiche welcher HTML-Code bestimmt ist, und ihn dann entsprechend an die lokale AJAX-Anwendung übergeben kann, die diesen HTML-Code dann an die richtigen Stellen im DOM der Seite schreibt. Eine unabdingbare Voraussetzung für die Verwendung von AJAX. (“osCommerce” zu AJAX-ifizieren wäre m.E. ein unmögliches Unterfangen!)

Im Prinzip braucht für AJAX der funktionelle Ablauf von olCommerce nicht geändert zu werden, da man ja erst dann eingreifen muss, wenn die fertigen HTML-Daten vorliegen. Allerdings bietet es sich natürlich mit AJAX an, nur noch diese Teile wirklich neu zu erstellen, die auch benötigt werden. Beim konventionellen Verfahern muss man halt immer alle (27) möglichen änderbaren Bereiche neu berechnen, da diese zur Erstellung der kompletten Seite benötigt werden, auch wenn sich von der Sache her nur einer(!) dieser Bereiche wirklich geändert hat (z.B. bei der Ablage eines Artikels in den Warenkorb ändert sich nur der Warenkorb). Deshalb haben wir auch in den funktionellen Ablauf von olCommerce eingegriffen, um die zu übertragenden Daten anwendungsorientiert zu minimieren (was erfreulicherweise in nur einer olCommerce-Routine möglich war). Neben dem unschlagbaren Gewinn an Ergonomie wird man damit auch eine Menge an PHP- und Datenbankbefehlen sparen.

Allerdings muss man schon erhebliche Eingriffe in olCommerce vornehmen, da die AJAX-ifizierung einige notwendige Voraussetzungen hat.

z.B. müssen alle Formulare jetzt ein “onsubmit“event bekommen (warum siehe weiter unten), für die Validierung benötigen die meisten Felder “onchange” bzw. “onblur”-Events”, und alle Links müssen so modifiziert werden, dass der AJAX-Mechanismus überhaupt greifen kann (Links werden in eine Javascript-Funktion gewrapped, die den AJAX-Verkehr abwickelt), u.v.m..

Glücklicherweise betrifft das meist zentrale Routinen (“meist” nur deshalb, weil in “Open Source” Systemen mit vielen Vätern und Müttern halt die Disziplin nicht immer gegeben ist, diese zentralen Routinen auch zu verwenden. So musste man olCommerce erst mal standardisieren, damit überall diese zentralen notwendigen Routinen verwendet werden).

=====================

Getestet ist das Ganze mit IE 6, FireFox 1.5 und Netscape 8.1

Es gibt sicher noch ein paar Dinge, die noch nicht richtig funktionieren, aber ich denke, das Ganze ist schon recht stabil und man kann sich doch schon einen sehr guten Eindruck von den Möglichkeiten des von olc/AJAX machen.

Die Navigation funktioniert so weit, der Einkauf auch, ebenso auch die Browser-Historie (ein besonderes Problem mit AJAX, da der ganze Verkehr mit dem Server am Browser vorbeiläuft!).

Besonders bemerkenswert ist, dass bei allen Funktionen der Bildschirm nicht mehr gelöscht wird, sondern stabil bleibt. Das Internet-Anwendungs-typische Gezappel und Geruckel am Bildschirm beim Aufruf neuer Funktion gehört damit der Vergangenheit an.

Die Realtime-Validierung ist soweit auch fertig.

Es können validiert werden:

Vorname/Geschlecht (Von “Aafke (weiblich)” bis “Zümrüt (weiblich)”)

Für D-A-CH:

PLZ (mit automatischem setzen von Stadt (und Bundesland für D), wenn die PLZ gefunden wurde)

BLZ (mit automatischem setzen der Bank, wenn die BLZ gefunden wurde)

Für D:

Prüfen der Kontonummer auf Gültigkeit anhand des Prüfziffernverfahrens der jeweiligen Bank.

Für alle Online-Validierungen gilt:

Werden für die eingegebenen Werte mehrere Einträge gefunden (man kann auch Teile eines Begriffs eingeben), wird unter dem betreffenden Feld eine Auswahlbox mit den gefundenen Alternativen angezeigt, aus denen dann die richtige gewählt werden kann. (Im Regelbetrieb wird man das tunlichst vermeiden, aber derzeit kann man sich alle 46.431 Vornamen, 19.241 BLZ und 26.564 PLZ auf diese Art zur Auswahl anbieten lassen. (Da hat der Browser doch ein paar Sekunden zu tun, um diese Auswahlboxen in die Seite einzubauen.) Im Regelbetrieb wird für die Eingabe eine Mindestanzahl einzugebender Zeichen vorgeschrieben, um die Auswahlmöglichkeiten zu reduzieren.)

Fehler und Hinweise werden nun über die gewohnte WINDOWS-Messagebox (“alert” in Javascript) mitgeteilt.

Als kleine Spielerei (um die Möglichkeiten des Verfahrens zu testen) ist es auch vorgesehen, dass bei der Änderung des Landes in der Kundendatenmaske die Bundesländer des jeweiligen Landes im “Bundesland“-Feld erscheinen, bzw. das ganze Bundesland-Feld entfernt wird, wenn es keine Bundesländer gibt.

Validiert wird auch die “Schnellkauf”-Funktion, wo entweder ein Fehler angezeigt wird (“Artikel-Nr. falsch”, “Produkt ausverkauft” u.ä.), oder der Warenkorb aktualisiert wird.

Alles also so, wie man es von lokalen Anwendungen üblicherweise gewohnt ist

==========================

Implementiert ist auch etwas, was ich “sticky cart“ getauft habe, also ein Warenkorb, der beim Scrollen auf einer Kategorie-Produkt-Seite am rechten Rand “angeklebt” (deshalb “sticky”) und sichtbar bleibt, so dass man bei weiterem Einkauf auch beim scrollen gleich den aktuellen Stand sieht. (Mich jedenfalls hat das immer gestört, dass ich beim Einkauf nie den Warenkorb sehen konnte, wenn dieser aus dem Bildfeld gescrolled war. Mit AJAX kann man, als Nebeneffekt, diesen jetzt sehr schön immer sichtbar und aktuell halten.)

==========================

So schön AJAX auch ist, es schafft doch eine ganze Reihe von Problemen, die man anwendungsorientiert lösen muss.

Die wichtigsten sind:

1. Der Browser leistet keine gewohnten Dienste mehr

Das AJAX-Programm muss z.B. selbst für die richtige Aufbereitung von Sonderzeichen sorgen.

2. Der Browser ermittelt keine POSTDaten

Das AJAX-Programm muss beim POST von Formulardaten (“onsubmit”) selbst die richtigen Parameter aus dem Formular ermitteln (ein nicht ganz triviales Problem).

Der ganze mittlerweile in olCommerce vorhandene Komfort hat natürlich auch seinen Preis:

das olc/AJAX-Javascript das den ganzen AJAX-Verkehr, den lokalen Teil der Validierung, den “sticky-cart” und die “Browsing-Historie” abwickelt, hat mittlerweile 2.500(!) Zeilen (der Lesbarkeit wegen allerdings großzügig formatierten) Code. Das ist aber nicht weiter tragisch, da der ja nur einmal beim Start der Anwendung geladen wird, und bei den einzelnen Programmschritten jeweils immer nur kleine Teile daraus benötigt werden.