Ich würde mal sagen, dass alle Beteiligten tief durchatmen sollen und die Diskussion betreffend Vor- und Nachteile Ajax im Oxid-Shopsystem auf einer angenehmeren Ebene weiterführen.
Hast Dich als eventueller Auftragnehmer voll disqualifiziert.
Da bin ich aber jetzt ganz traurig…
Gerade bei Heise.de gelesen, vielleicht passt es ja in diesen thread
http://www.heise.de/newsticker/meldung/Google-will-in-manchen-Ajax-Seiten-suchen-822060.html
Jein.
Ich verfolge da eine andere Lösung:
Wenn eine Suchmaschine den Shop besucht wird er nicht in den AJAX-Betrieb geschaltet.
Dann ist alles so wie immer.
Ich habe mir heute (zur Entspannung…) mal wieder etwas Zeit genommen, um diese Version voran zu bringen.
[B]Zunächst aber noch ein weiterer systemimanenter Performance-Vorteil des AJAX-Komplett-Betriebs:[/B]
Es ist zwar richtig, dass auch im [B]Normalbetrieb [/B]die CSS- und Javascript-Dateien [B]nur einmal[/B] übertragen werden.
[B] Aber: [/B]
Im [B]Normalbetrieb [/B]müssen die CSS-Anweisungen [B]bei jedem Seiten-Reload[/B] neu interpretiert und angewandt, und die Javascript-Module neu kompiliert werden.
Im [B]AJAX-Betrieb[/B] aber [B]nur beim Shop-Start[/B]!
Es wird also auch dadurch weniger Arbeit im Browser anfallen (zusätzlich zum reduzierten Datentransfer und dem nicht mehr notwendigen Neuaufbau des DOM)…
[B]Was ist neu in dieser Version?[/B]
In ihr wurde die Idee umgesetzt, bei [B]Bestellungen [/B]nur noch den [B]Mini-Warenkorb-Inhalt [/B]vom Server zu übertragen, und die aktuelle Position im Browser nicht zu verändern, so dass man bequem aus einer Produkt-Liste weiter shoppen kann, [B]ohne [/B]erst wieder scrollen zu müssen…
Wenn im Shop-Content-Bereich Funktionen enthalten sind, [B]die einen Einkauf ermöglichen[/B], dann wird rechts neben dem Shop ein zusätzlicher Warenkorb angezeigt, der [B]immer sichtbar [/B]ist.
Wenn man nun z.B. die Kategorie “[B]Geschenke[/B]” anwählt, so weit nach unten scrollt, dass die Kategorien-Navigation im Content-Bereich nicht mehr sichtbar ist (man also nur noch die Produkte sieht), dann kann man aus dieser Liste nacheinander Produkte einkaufen, [B]ohne [/B]dass man seine Position in der Browser-Seite verliert.
Der immer sichtbare Zusatzwarenkorb zeigt die Änderungen in den Bestellungen an…
Und hier wird vom Server [B]nur noch[/B] der neue [B]Mini-Warenkorb-Inhalt [/B]übertragen, da sich ja sonst im Shop nichts ändert…
[B] Das sind dann nur noch schlanke 0,5 KB statt der sonst notwendigen 45 KB!!![/B]
Und berechnet wird dabei von den “Boxen” auch nur die Mini-Warenkorb-Box!
(Im Moment wird der “[B]main_content[/B]” auch noch berechnet (aber nicht übertragen).
Aber da fällt mir sicher auch noch eine Lösung ein, wie ich OXID dazu veranlassen kann, sich diese Arbeit zu sparen…
[B]
Hat dazu jemand zufällig schon mal eine Idee???[/B])
Ich denke, dass diese neue Funktionalität ein sehr schönes Beispiel ist, wie [B]elegant [/B]man mit AJAX einen Shop gestalten kann…
Überhaupt werden auch alle [B]Blätterfunktionen mit AJAX [/B]angenehmer werden, da man nicht jedes mal wieder an den Seitenanfang zurück geworfen wird, und erst mal wieder zur Blättersteuerung scrollen muss.
Und man kann sicher auch noch andere Shop-Abläufe finden, für die man den Datentransfer vom Server minimieren kann…
(So adhoc fällt mir da als weiteres Beispiel die Anzeige von CMS-Inhalten an, wofür man eigentlich keine “Box” neu berechnen und übertragen müsste, sondern nur den neuen “[B]main_content[/B]”…)
[B]Wenn da noch jemand Ideen hat, welche Abläufe so zu optimieren wären, immer her damit![/B])
Es sind nach wie vor [B]keine [/B]Änderungen am OXID-Core notwendig, der AJAX-Betrieb ist für die Shop-Software immer noch [B]voll transparent[/B], die weiß gar nichts von ihrem Glück…
[B]Der AJAX-Betrieb ist weiterhin nur [/B][B]mit dem FireFox-Browser getestet![/B]
Hier geht es zu neuen Version: http://www.powertemplate.de/kunden/oxid_ajax/index.php
[B]Ach ja:[/B]
Der Shop hat jetzt auch ein schönes [B]“AJAX”-Siegel[/B] bekommen, damit man sofort sieht, [B]dass[/B] er sich im AJAX-Betrieb befindet…
======================================================
Bei der Arbeit an dieser Funktion ist mir ein merkwürdiges Verhalten des Shops aufgefallen:
Wenn ein Produkt in den Warenkorb gelegt wird, dann führt der Shop diese Funktion aus.
Aber anstatt dann weiter zu machen und die Ergebnisseite aufzubauen, macht er ein Server-Redirect zu einer neuen URL, und erst dann wird die Ergebnissseite aufgebaut…
Das erscheint mir im Moment etwas sinnfrei und nicht sehr optimal, da dann ja noch mal alle Shop-Objekte wieder neu aufgebaut werden müssen…
Weiß jemand, warum das so ist?
[QUOTE=avenger;16252]
Bei der Arbeit an dieser Funktion ist mir ein merkwürdiges Verhalten des Shops aufgefallen:
Wenn ein Produkt in den Warenkorb gelegt wird, dann führt der Shop diese Funktion aus.
Aber anstatt dann weiter zu machen und die Ergebnisseite aufzubauen, macht er ein Server-Redirect zu einer neuen URL, und erst dann wird die Ergebnissseite aufgebaut…
Das erscheint mir im Moment etwas sinnfrei und nicht sehr optimal, da dann ja noch mal alle Shop-Objekte wieder neu aufgebaut werden müssen…
Weiß jemand, warum das so ist?[/QUOTE]
Der Sinn erschließt sich mir auch nicht wirklich.
Ich vermute entweder:
[ul]
[li]Der Warenkorb ist schon vorher berechnet und muss mit den zusätzlichen Artikel neu berechnet werden… das geht eigentlich eleganter.
[/li][li]Dies passiert bei allen oxcmp… Methoden(??) und wird aus Sicherheit wegen (vorheriger Punkt) so gemacht. Dies könnte man aber mit wenigen statischen Variablen in der oxcmp-Klasse auch definieren, ob dies so notwendig ist.
[/li][li]Es ist (in Zukunft) angedacht, hier aus den Formular wieder eine eindeutige SEO-URL zu erzeugen.
[/li][/ul]
Na ja, never touch a running system oder kontinuierliches Refactoring was ist wichtiger?
[QUOTE=worner;16257]@avenger
bei mir kommt beim Linkaufruf folgendes:
(siehe Anhang)[/QUOTE]
Welcher Link war das ?
Und welcher Browser?
Ich habe das noch genauer untersucht…
Und einfach mal den “Redirect”-Befehl auskommentiert.
Und siehe da: funktioniert (Lade-Timeline in Grafik " buy_without_redirect.jpg" im Anhang)
Insgesamt braucht der Shop dafür 5,07 Sekunden…
Und dann das Ganze nochmal mit “Redirect”. (Lade-Timeline in Grafik " buy_with_redirect.jpg" im Anhang)
Insgesamt braucht der Shop dafür 7,37 Sekunden…
Das sind 2,37 Sekunden, bzw. 47% länger als im ersten Fall…
[B]Die Zeit sollte man sich sparen, ist anscheinend völlig nutzlos…[/B]
Komisch…
hatte nochmal probiert dann war es o.k.
Jetzt nochmal probiert, dann kommt die gleiche Fehlermeldung wie oben.
Link geklickt im Posting von gestern 12.32
Firefox 3.6
[QUOTE=avenger;14663]
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…)
[/QUOTE]
Guten Morgen avenger.
Würdest Du mir verraten (den kurzen Code zum Anschauen), wie Du die Prüfung auf JS-Fähigkeit realisiert und in die Module eingebunden hast?
Im Übrigen habe ich Deinen Ansatz mit den Boxen beim Erstversuch nicht zum Laufen gebracht (denke aber ich weiss woran es gelegen hat) und dann selbst in meinem Bedarf entsprechend nachgebaut und für meine Zwecke erweitert. Und da ich eben auch bestimmte Kleinigkeiten mit Ajax lösen möchte statt immer den kompletten Code neu zu senden, würde ich mich für diesen Ansatz mit der JS-Prüfung sehr interessieren.
Im Voraus Danke…
Hallo an Alle…
Hat ein anderer eine Idee, wie man eine Prüfung ob JS aktiviert ist sinnvoll einbauen könnte um sozusagen 2 Wege bereitzustellen. Und wie man diese Prüfung wie Avenger beschrieben hatte an die User- oder eine andere Klasse anhängen kann um es evtl. als Smarty-Variable zur Verfügung zu haben?
Gruss.
Ich denke du kannst per php erstmal nicht herausfinden ob der user javascript aktiviert hat, die seite sollte immer so aufgebaut sein das bei deaktiviertem Javascript die normale Funktion erhalten bleibt bzw. per <noscript> ermöglicht wird. Aber klärt mich auf wenn das in irgendeinem header doch steht.
Warum ist der SHop Offline?
Hier geht es zu neuen Version: http://www.powertemplate.de/kunden/oxid_ajax/index.php
Würde mir das auch gern mal angucken.