OXID CE goes AJAX

Im Thread http://www.oxid-esales.com/forum/showthread.php?p=14544#post14544 hatte ich ja schon angedeutet, dass mit meinem neuen Templating-Konzept jetzt auch die Möglichkeit besteht, den Shop komplett im AJAX-Betrieb zu fahren.

Also nicht nur Teile im Hintergrund nachzuladen, sondern den kompletten Verkehr zwischen Browser und Server über AJAX abzuwickeln.

Damit entfällt das Neuladen der Shop-Seite im Browser nach jedem Klick, weil nur bestimmte Bereiche im Bildschirm ausgetauscht werden.

Es entsteht das von Desktop-Anwendungen bekannte Verhalten von Anwendungen.

Ein weiterer Vorteil ist, dass man einige Bildschirm-Elemente nur [B]beim ersten Laden[/B] des Shops übertragen muss und sonst nicht mehr!

Das sind der Shop-[B]Header[/B], -[B]Footer [/B]und eine Reihe von [B]Boxen [/B]die statisch sind.

Und das sind eine ganze Menge…

box_CONTENT
box_CURRENCIES
box_HOME_LINK
box_LANGUAGES
box_MANUFACTURERS
box_MENUE_LIST_LINK
box_NEWS
box_NEWSLETTER
box_PARTNERS
box_SEARCH
box_SERVICE
box_TOP_LINKS
box_TOP_NAVI
box_TOP_NAVI_LINKS
box_VENDORS
box_WHISLIST_LINK

Diese OXID/AJAX-Version ist fast fertig, bin selbst erstaunt, wie gut das geht…

Es erfolgt auch eine Prüfung, ob der Browser überaupt Javascript unterstützt…

Wenn ja, wird der AJAX-Modus verwendet, sonst läuft der Shop ganz normal…

[B]Und: Das Ganze ist voll transparent für die Shop-Software![/B]

Und erfordert erstaunlich wenig Code…

Plus natürlich ein “wenig” Javascript für die AJAX-Steuerung und andere Funktionen.

Realisiert wurde das Ganze durch 2 (sehr überschaubare) Module:
(das sind nur schlanke [B]115 Zeilen[/B] PHP-Code für beide Module…)

Eine eigene Klasse, die an die “oxuser” -Klasse andockt, und die am Anfang die Prüfung auf Javascript-Unterstützung macht, und im folgenden auf Arbeit im AJAX-Modus prüft. (Die Klasse hat natürlich gar nichts mit dem “User” zu tun, aber die “oxuser”-Klasse wird halt bei jeder Shop-Funktion gestartet, so dass mein Code immer da ist…)

Und dann muss ich vor dem Rendern der zentralen Seite “[B]_index.tpl[/B]” nur noch prüfen, ob der Shop im AJAX-Modus ist, oder nicht (was in der zum neuen Templating-Konzept gehörenden “_boxes.php”.geschieht)

Wenn der Shop nicht im AJAX-Modus ist, wird die “[B]_index.tpl[/B]” ganz normal gerendert und übertragen (sonst nur beim [B]ersten [/B]Start).

Andernfalls werden die (ja in “Smarty” verfügbaren) HTML-Daten der “[B]Boxen[/B]” und des “[B]main_content[/B]” (identifizierbar) in einen XML-Datenstrom gepackt und versendet.

Im Browser wird der Datenstrom dann per Javascript wieder aufgespalten, und die neu gesendeten DOM-Elemente der Seite werden ausgetauscht.)

Das notwendige Javascript ist um einiges schwieriger, als der PHP-Teil, da es eine ganze Reihe von Problemen zu lösen gibt.

Dabei greife ich teilweise auf Lösungen anderer Entwickler zurück:

“[B]JSMX[/B]” für den Datenverkehr zwischen Browser und Server ( http://www.lalabird.com/ )

“[B]dsHistory[/B]” für die Lösung des Browser Vor- und Zurück-Button AJAX-Problems (“Browser History”). ( http://code.google.com/p/dshistory/ )

Um überhaupt den AJAX-Verkehr möglich zu machen, müssen natürlich [B]alle [/B]Klicks auf Links und Submit-Buttons ihre ursprüngliche Funktion verlieren.

Um dafür ohne Shop-Codeänderungen auszukommen, werden beim Laden von HTML-Elementen per Javascript die entsprechenden Elemente auf die neuen Event-Handler umgeleitet, so dass der Datenverkehr vollständig über AJAX laufen kann…

Die Entwicklung ist schon recht weit fortgeschritten, die grundlegenden Probleme sind gelöst.

Ich schätze, dass in ca. 2 bis 3 Wochen das ganze demonstrierbar ist. ( Muss jetzt erst mal wieder was anderes machen…)

Möglich wird das Ganze [B]nur [/B]durch die Verwendung von [B]Smarty ([/B]und die Restrukturierung des Templatings), weil man jetzt identifizierbare Elemente adressieren kann…

Und die entsprechen erfreulicherweise genau solchen Elementen des Shop-Bildschirmlayouts, die man gezielkt austauschen kann.

Also:

“[B]Finger weg von Smarty![/B]”

Ohne Smarty wäre OXID nur noch halb so schön (höchstens!)…

Das höhrt sich nicht schlecht an! Du bekommst bestimmt bald ein Jobangebot von der OXID AG! Ich hoffe, dass Du später auch die Installation für Leute erklärtst, für die AJAX nur ein Putzmittel ist. :rolleyes:

Finde ich auch sehr gut. Wird es Demo zu sehen geben?

Gruß

[QUOTE=MothersCoffee;14676]Das höhrt sich nicht schlecht an! Du bekommst bestimmt bald ein Jobangebot von der OXID AG! Ich hoffe, dass Du später auch die Installation für Leute erklärtst, für die AJAX nur ein Putzmittel ist. :rolleyes:[/QUOTE]
Da gibt es nicht viel zu installieren…

Einfach Dateien kopieren, und einen Eintrag bei den Modulen im Admin…

Aber wie gesagt, das basiert auf dem [B]neuen [/B]Template-Konzept.

Bestehende Shops mit anderem als dem Standard-OXID-Template kann man da nicht so einfach nachrüsten…

Obwohl man natürlich im Prinzip jedes OXID-Template so umbauen kann, dass es passt…

[QUOTE=fragarena;14684]Finde ich auch sehr gut. Wird es Demo zu sehen geben?

Gruß[/QUOTE]
Ja, ich hoffe in 2 bis 3 Wochen so weit zu sein…

Was natürlich auch nur einmal geladen werden muss sind die CSS- und Javascript-Dateien, die ja auch nicht gerade klein sind.

Insgesamt sollte man bei langsamen Verbindungen doch eine Menge Traffic .sparen können.

Das hört sich doch sehr interessant an.
Bin gespannt wie du das umgesetzt hast und erwarte ungeduldig das Modul/Demo.

Gruß
Benny

echt mal feine sache…da bin ich wie die anderen sehr sehr gespannt.

wenn ich für den “standard” shop meine anpassungen in den tpl und css gemacht habe, krieg ich das dann überhaupt noch “umgezogen”?

des weiteren habe ich die product.tp in mehrfacher ausführung, da sich mein design enorm von den darstellungen unterscheidet war es für mich (als anfänger) mehrere product.tpl anzulegen und entsprechend aus details, list usw aufzurufen.

war das ein fehler? auch aus performance gründen? eigtl. nicht, oder?

da ich eh noch nicht fertig bin, werde ich auf jeden fall auf dein baby warten und ggf. von vorne anfangen. wie ich das gelesen habe, lohnt es sich.

hat ajax auch nachteile? wenn man dich liest nicht :smiley:

[QUOTE=racoon;14739]echt mal feine sache…da bin ich wie die anderen sehr sehr gespannt.

wenn ich für den “standard” shop meine anpassungen in den tpl und css gemacht habe, krieg ich das dann überhaupt noch “umgezogen”?

des weiteren habe ich die product.tp in mehrfacher ausführung, da sich mein design enorm von den darstellungen unterscheidet war es für mich (als anfänger) mehrere product.tpl anzulegen und entsprechend aus details, list usw aufzurufen.

war das ein fehler? auch aus performance gründen? eigtl. nicht, oder?

da ich eh noch nicht fertig bin, werde ich auf jeden fall auf dein baby warten und ggf. von vorne anfangen. wie ich das gelesen habe, lohnt es sich.

hat ajax auch nachteile? wenn man dich liest nicht :D[/QUOTE]
Man kann jedes Template auf die neue Struktur umstellen, das ist ja “nur” eine andere Art der Zusammenstellung,

Im wesentlichen läuft das auf Änderungen der “_xxxx.tpl”-Dateien hinaus, aus denen die Template-Teile, die “Boxen” darstellen, extrahiert und in eigene “box_xxxxxxx.tpl”-Dateien separiert werden.

Dem AJAX-Modus ist es völlig egal, [B]wie [/B]der HTML-Code für die Seiten entsteht.

Da das ganze transparent sein sollte, setze ich erst auf einer sehr tiefen Ebene an, nämlich dann, wenn der HTML-Code der einzelnen Elemente fertig gerendert ist (also vor dem Rendern der “_index.tpl”).

AJAX hat m.E. keine Nachteile.

Außer für den Implementierer, der ein paar knifflige Probleme lösen muss…

z.B. funktionieren im AJAX-Betrieb die Browser Vor- und Zurück-Buttons nicht mehr richtig, da beim Laden über AJAX die Browser-History nicht aktualisiert wird.

Man muss da schon einige (Javascript-)Klimmzüge machen, um das dennoch zu erreichen, damit der Surfer das gewohnte Verhalten wieder findet… (Ein paar schlaue Jungs haben dafür Lösungen erdacht.)

Ein anderes Problem ist, dass im AJAX-Betrieb (aus Sicherheitsgründen) nur Seiten von der URL geladen werden dürfen, von der aus das Prog gestartet wurde.

Was zunächst mal zu Problemen mit dem ganzen Payment führen kann, das über externe Server abgewickelt wird…

Aber auch das ist lösbar, indem man ein Proxy-Programm im Shop dazwischen schaltet, das den Verkehr mit den externen Serven regelt.

Einen kleinen Nachteil gibt es evtl. doch:

AJAX erlaubt (warum auch immer) auch nicht die Umschaltung vom http in den https-Modus, selbst nicht auf derselben Domain…

Wenn also der Shop in der Bestellabwicklung einen https-Server verwendet,[B] muss der gesamte Verkehr von Anfang [/B]an über https laufen.

Diese Umschaltung wird auch von dem Programm-Teil veranlasst, der prüft, ob der Browser Javascript aktiviert hat.

Dazu wird ein kleines HTML-Progrämmchen in den Browser geladen, das einfach das Programm wieder aufruft, je nach aktiviertem Javascript oder nicht auf verschiedene Arten. Daraus kann man dann erkennen, ob JS aktiviert ist. Und wenn https verwendet werden muss, erfolgt dieser Aufruf über https, auch wenn das Programm ursprünglich über http aufgerufen wurde.

Ist halt alles nicht so einfach, aber lösbar…

Wie sieht es mit anderen Nachteilen von AJAX aus?

  • das Suchmaschinen AJAX nicht verstehen
  • das durch AJAX aufgerufene informationen nicht als LINK verfuegbar sind und nicht als bookmark gespeichert oder versandt werden koennen
  • hoehere Serverauslasstung weil mehrere Einzelanfragen gemacht werden.

[QUOTE=bitconstructor;14763]Wie sieht es mit anderen Nachteilen von AJAX aus?[/QUOTE]

[QUOTE=bitconstructor;14763]

  • das Suchmaschinen AJAX nicht verstehen
    [/QUOTE]
    Kein Problem: wenn eine Suchmaschine den Shop besucht (was OXID ja entdeckt), wird der halt nicht in den AJAX-Modus geschaltet, und arbeitet ganz konventionell…

[QUOTE=bitconstructor;14763]

Und: man kann nicht alles haben…

Wem die Links und Bookmarks mehr wert sind, als ein AJAX–betriebener Shop, der lässt das halt sein.

[QUOTE=bitconstructor;14763]

  • hoehere Serverauslasstung weil mehrere Einzelanfragen gemacht werden.
    [/QUOTE]
    Wie kommst Du darauf?

Der Ablauf für den Server ist (bei meiner Implementierung) [B]deutlich geringer,[/B] da viele Elemente gar nicht mehr gerendert, und CSS und JS nur einmal geladen werden.

Es gibt auch nur [B]einen [/B]Request pro Click, wie normalerweise auch.

Man muss halt Erfahrungen damit sammeln…

Erst mal vielen vielen Dank für diesen tollen Ansatz.

Das mit den URL für natürlichen Linkaufbau müsste im Echtbetrieb gelöst werden. Wer auf natürlichen Linkaufbau verzichtet, verzichtet auf seine Zukunft.

[QUOTE=Voltus;14782]Erst mal vielen vielen Dank für diesen tollen Ansatz.

Das mit den URL für natürlichen Linkaufbau müsste im Echtbetrieb gelöst werden. Wer auf natürlichen Linkaufbau verzichtet, verzichtet auf seine Zukunft.[/QUOTE]
Und was soll uns das jetzt sagen?

Ich bin kein Techniker aber im Onlinemarketing erfahren. Der Kollege hat mit der Frage bezüglich dieses Aspektes die richtige Frage gestellt. Ich hoffe das hier Jemandem ein Lösungsansatz einfällt.

[QUOTE=Voltus;14784]Ich bin kein Techniker aber im Onlinemarketing erfahren. Der Kollege hat mit der Frage bezüglich dieses Aspektes die richtige Frage gestellt. Ich hoffe das hier Jemandem ein Lösungsansatz einfällt.[/QUOTE]
Wo ist das Problem???

Was ist das Problem?

a)
Besucher haben keine Ahnung von AJAX, wollen nur surfen und sind sich gewohnt URLS aus der Adresszeile zu speichern (bookmark) oder an freunde zu schicken. Falls alles auf einer Seite mit AJAX eingeholt wird funktioniert das nicht mehr.

Wenn du sagst “Wem die Links und Bookmarks mehr wert sind, als ein AJAX–betriebener Shop, der lässt das halt sein.” dann macht es den Eindruck es gehe dir mehr um AJAX als um die Besucher, bzw. du scheinst die Wichtigkeit dieser Aspekte nicht verstanden zu haben.

b)
Entwickler versuchen ALLES mit AJAX umzusetzen anstatt zu schauen wo AJAX hilfreich ist und wo es schlicht nicht praktisch od. notwendig ist.

Bin selbst Webentwickler und kenne das von meinen Angestellten sehr gut :slight_smile: Die wollen immer alles mit AJAX machen.

Es macht Sinn AJAX zu verwenden bei Sachen die nachgeladen werden koennen/sollen. z.b. Detailvorschau von einem produkt gleich auf der startseite (mit einem [+] link).

c) Server Load:
Wir haben etliche Systeme (CRM, …) selbst entwickelt und bei einigen fast alles mit AJAX umgesetzt.
Die Serverlast ist x fach groesser da pro Request eine Speichermenge reserviert wird fuer den PHP Prozess, und bei AJAX x fach mehr Requests gestartet werden. Dh. weniger benutzer koennen einen Server beanspruchen.
Ein Server request der etwas laenger dauert weil die Seite komplett berechnet wird macht den Server nicht unbedingt langsamer. Wozu gibt es internes Caching? Es muss ja nicht jedes mal ALLEs neu berechnet werden.

(zum nachdenken: warum laden grosse Betreiber wie amazon, ebay etc. nicht alles ueber AJAX sondern laden fast komplette Seiten neu?)

d)
Langsamere Clients (also die meisten der Webbesucher) und aeltere Browser sind viel langsamer mit AJAX. Pro zugriff muss da jedes mal die DNS aufgeloest werden, der browser cache abgefragt werden, die Verbindung hergestellt werden. in vielen Laendern ausserhalb Europas ist die Internetverbindung nicht so gut, und die Verbindungsherstellung zum Server kann schon mal 2sek dauern.

Zudem brauchen nachladende Teile immer mehr Speicher im Browserprozess. (nicht jeder hat google chrome!)

e)
CSS, JS etc. wird sowieso NUR 1x geladen wenn es korrekter weise in externen Dateien abgelagert ist, dh also hier kein Geschwindigkeitsvorteil bei AJAX

AJAX hat auch seine Vorteile, die ich nicht abschwaechen moechte, sie sind jedoch auf bestimmte Szenarien beschraenkt.
Die muessen aber klar mit dem Verwendungszweck und den Nachteilen abgewogen werden.

[QUOTE=bitconstructor;14813]
a)
Besucher haben keine Ahnung von AJAX, wollen nur surfen und sind sich gewohnt URLS aus der Adresszeile zu speichern (bookmark) oder an freunde zu schicken. Falls alles auf einer Seite mit AJAX eingeholt wird funktioniert das nicht mehr.

Wenn du sagst “Wem die Links und Bookmarks mehr wert sind, als ein AJAX–betriebener Shop, der lässt das halt sein.” dann macht es den Eindruck es gehe dir mehr um AJAX als um die Besucher, bzw. du scheinst die Wichtigkeit dieser Aspekte nicht verstanden zu haben.
[/QUOTE]
Die “ungeheure Wichtigkeit” des Bookmarkings ist in der Tat bisher an mir total vorbei gegangen…

Und wie ich schon sagte: Auch dafür gibt es Lösungen.

[QUOTE=bitconstructor;14813] b)
Entwickler versuchen ALLES mit AJAX umzusetzen anstatt zu schauen wo AJAX hilfreich ist und wo es schlicht nicht praktisch od. notwendig ist.

Bin selbst Webentwickler und kenne das von meinen Angestellten sehr gut :slight_smile: Die wollen immer alles mit AJAX machen.

Es macht Sinn AJAX zu verwenden bei Sachen die nachgeladen werden koennen/sollen. z.b. Detailvorschau von einem produkt gleich auf der startseite (mit einem [+] link).[/QUOTE]
Nun, Google sieht das bei seinen Anwendungen ganz anders: GMail, WAVE und was es da sonst noch gibt nutzen AJAX ohne Ende. Yahoo-Mail ebenso.

[QUOTE=bitconstructor;14813]
c) Server Load:
Wir haben etliche Systeme (CRM, …) selbst entwickelt und bei einigen fast alles mit AJAX umgesetzt.
Die Serverlast ist x fach groesser da pro Request eine Speichermenge reserviert wird fuer den PHP Prozess, und bei AJAX x fach mehr Requests gestartet werden. Dh. weniger benutzer koennen einen Server beanspruchen.
Ein Server request der etwas laenger dauert weil die Seite komplett berechnet wird macht den Server nicht unbedingt langsamer. Wozu gibt es internes Caching? Es muss ja nicht jedes mal ALLEs neu berechnet werden.

(zum nachdenken: warum laden grosse Betreiber wie amazon, ebay etc. nicht alles ueber AJAX sondern laden fast komplette Seiten neu?)[/QUOTE]
Nun, dann habt ihr etwas ganz furchtbar falsch gemacht!

Noch mal zum mitschreiben: PRO KLICK IM SHOP GIBT ES AUCH IM AJAX-BETRIEB NUR EINEN REQUEST AN DEN SERVER, nur dass eben weniger Daten übertragen werden müssen.

[QUOTE=bitconstructor;14813] d)
Langsamere Clients (also die meisten der Webbesucher) und aeltere Browser sind viel langsamer mit AJAX. Pro zugriff muss da jedes mal die DNS aufgeloest werden, der browser cache abgefragt werden, die Verbindung hergestellt werden. in vielen Laendern ausserhalb Europas ist die Internetverbindung nicht so gut, und die Verbindungsherstellung zum Server kann schon mal 2sek dauern.[/QUOTE]
Da bei meiner AJAX-Lösung auch nur ein Server-Request notwendig ist, ist sie da gegenüber konventionellen Lösungen nicht im Nachteil.

[QUOTE=bitconstructor;14813] Zudem brauchen nachladende Teile immer mehr Speicher im Browserprozess. (nicht jeder hat google chrome!)[/QUOTE]
Ja, und?

[QUOTE=bitconstructor;14813]e)
CSS, JS etc. wird sowieso NUR 1x geladen wenn es korrekter weise in externen Dateien abgelagert ist, dh also hier kein Geschwindigkeitsvorteil bei AJAX

AJAX hat auch seine Vorteile, die ich nicht abschwaechen moechte, sie sind jedoch auf bestimmte Szenarien beschraenkt.
Die muessen aber klar mit dem Verwendungszweck und den Nachteilen abgewogen werden.[/QUOTE]
Ja, sicher.

Wem es gefällt, der nutzt es, wem nicht der lässt es sein.

Und ich denke, jetzt haben wir alle sinnvollen Argumente für und wider die AJAX-ifizierung von ganzen Anwendungen ausgetauscht.

Ich werde es implementieren, einfach weil mich die Aufgabe reizt, eine Anwendung (transparent) vollständig zu AJAX-ifizieren.

Der Weg ist das Ziel…

Nun, Google sieht das bei seinen Anwendungen ganz anders: GMail, WAVE und was es da sonst noch gibt nutzen AJAX ohne Ende. Yahoo-Mail ebenso.

Das sind Clients die eine Desktop Anwendung simulieren sollen, da macht ajax ja auch sinn. bitconstructor sagte schon richtig, der Verwendungszweck machts.

aber wenn du das als experiment machen willst ists sicherlich ganz interessant.

Hi Avenger,

da stößt der technikverliebte auf ein paar Argumente und wird gleich maulig. Es geht doch gar nicht um das für und wieder.

Du hast da einen erstklassigen Ansatz. Um diesen in der Praxis anzuwenden müssen aber die Nachteile dieser Technik minimiert werden. Wenn Du da nicht den urteilen der Erfahrenen Shopbetreiber glaubst wird man die Technik nie ernsthaft in “richtigen” Shops anwenden können. Und das fände ich sehr schade. Vielleicht fällt ja einem anderen eine gute Lösung für die angesprochenen Problemstellungen ein.

[QUOTE=Voltus;14820]Hi Avenger,

da stößt der technikverliebte auf ein paar Argumente und wird gleich maulig. Es geht doch gar nicht um das für und wieder.

Du hast da einen erstklassigen Ansatz. Um diesen in der Praxis anzuwenden müssen aber die Nachteile dieser Technik minimiert werden. Wenn Du da nicht den urteilen der Erfahrenen Shopbetreiber glaubst wird man die Technik nie ernsthaft in “richtigen” Shops anwenden können. Und das fände ich sehr schade. Vielleicht fällt ja einem anderen eine gute Lösung für die angesprochenen Problemstellungen ein.[/QUOTE]
[B]Wie oft denn noch; für alle diese “Probleme” gibt es bereits Lösungen…[/B]

Bzw., [B]das sind gar keine [/B]Probleme.

Wenn man nämlich aus einer eigenen schlechten AJAX-Implementierung Rückschlüsse auf die Brauchbarkeit der Technologie zieht, ist das sicher kein generisches Problem…

Und wenn “erfahrene Shopbetreiber” Müll erzählen, muss ich das ja nicht glauben.