Isotope Struktur

Hi in die Runde,

ich bin zurzeit damit bemüht, für Isotope ein/e neue/s Payment (Zahlungsart) einzubauen und habe einfach mal eine bestehende Zahlungsart gecloned. Das funktioniert gut. Nun hat diese Zahlungsart (Paypal_PUI) einige neue Features der API v2, wie beispielsweise die Idempotency (https://developer.paypal.com/api/res...e/idempotency/). Daraus folgen aber einige Fragen:

Wenn ich eine GUID zur Erhaltung der Idempotenz generiere, so möchte ich diese (eigentlich!) in der Order (Bestellung) persistent machen. Wo kann ich das am besten tun?

Folgendes spricht aber dagegen: Wie ich gesehen habe, legt Isotope in tl_product_collection einen Cart (Einkaufswagen) type=cart an und speichert darin die Artikel. Beim Checkout legt Isotope dann für jedes einzelne Checkout je einen neuen Datensatz vom type=order an. Leider hat diese Order nichts mit einer Bestellung in Wortsinne zu tun, sondern bei jedem Checkout auf den gegebenen Cart wird aus dem Cart eine neue Order erstellt. Wenn also der Checkout fehlschlägt, dann wird aus demselben Cart wieder eine neue Order mit einer neuen uniqid gebildet. Daher kann für die Gewährleistung der Idempotenz konzeptionell die GUID nicht an die Order - , sondern müsste meiner Ansicht nach direkt an den Cart gebunden werden, da nur der Cart Idempotenz besitzen kann.

Könnte dazu jmd. ein paar Empfehlungen für "den korrekten Einbau der GUID" geben?

Ich finde leider kein Klassendiagramm vom Isotope und auch keine Sequenzdiagramme, so dass ich nicht genau erkennen kann, wie das System strukturiert ist und welche Vorstellungen die Entwickler beim Entwurf verfolgt haben.

Wie ich weiterhin bemerkt habe, besitzt das Model Order oder die dazugehörigen Interfaces keine Schnittstelle zum Cart. Es ist also nicht möglich folgendes zut tun $order->getCart(), um auf den Cart zuzugreifen und dort eine GUID zu schreiben.

Ich habe das zwar nachgebildet, aber es fügt sich - meiner Ansicht nach - nicht korrekt in das Isotope-System ein.

Daher würde ich mich über ein paar Tipps von den Entwickler*Innen freuen :D

Warum hat eine Order konzeptionell keine Schnittstelle zu ihrem Cart (bekommen)?
Warum werden Orders immer wieder neu generiert, wenn ein Checkout fehl schlägt?
Bleibt der Cart persistent, wenn die Order (das Checkout) erfüllt werden konnte? oder anders gefragt, wo sollte die GUID effektiv gespeichert werden, damit Idempotenz gewährleistet werden kann?

Über eine Antwort würde ich mich freuen!
Grüße vom Theo

Zitat:

---

Zitat von theobald

Warum hat eine Order konzeptionell keine Schnittstelle zu ihrem Cart (bekommen)?

---

Technisch kann es in Isotope eine beliebige Anzahl "Product Collections", also Sammlungen von Produkten geben. Beispielsweise der Warenkorb, die Bestellung, die Favoriten oder Wunschlisten. Insofern haben die nicht immer eine Beziehung. Allerdings gibt es das Feld "source_collection_id" (oder so ähnlich), bei einer Bestellung ist das die ID des Warenkorbs. Über Model::getRelated() solltest du so von der Bestellung an den Warenkorb kommen, falls der Warenkorb noch vorhanden ist.

Zitat:

---

Zitat von theobald

Warum werden Orders immer wieder neu generiert, wenn ein Checkout fehl schlägt?

---

Weil sich der Warenkorb geändert haben kann. Wenn der Zahlvorgang nicht erfolgreich ist, kannst du ja in den Warenkorb und wieder was löschen.

Zitat:

---

Zitat von theobald

Bleibt der Cart persistent, wenn die Order (das Checkout) erfüllt werden konnte? oder anders gefragt, wo sollte die GUID effektiv gespeichert werden, damit Idempotenz gewährleistet werden kann?

---

Nein, der Cart wird gelöscht wenn die Bestellung abgeschlossen ist. Weil du dir ja dann einen neuen Warenkorb mit neuen Produkten für eine neue Bestellung anlegen kannst.


Für deinen Fall, wird denn die GUID nicht neu generiert wenn die Zahlung neu gemacht wird (und sich ggf. das Total ändert)? Du kannst die GUID entweder in den "payment_data" der Bestellung speichern (während des Bestellprozesses), oder du speicherst sie im Cart und kopierst sie bei erfolgreichem Abschluss in die Order.

vielen Dank! Das ist schon mal was. Das hilft mir weiter...

Ich habe jetzt eine eigene CheckoutPage als single page application für die PayPal-API v2 entworfen. Diese page arbeitet mit einem Ajax-Controller zusammen. Der Ablauf ist so ähnlich, wie beim Isotope-Standard-Checkout - nur eben alles über eine single page application.

Da stoße ich auf ein schwieriges Verhalten, dass ich mir nicht erklären kann. Das Problem ist folgendes.

1. Ein FrontendModul (neues Checkout) stellt die Rohdaten bereit und rendert via Twig den Content einmalig.
2. Dazu holt sich das Modul den aktuellen $cart = Isotope::getCart()
3. Meist handelt es sich hier nur um die Darstellung der Artikel im Warenkorb. Die anderen Elemente, wie Versandart oder Zahlungsart etc. sind (noch) nicht ausgewählt/initialisiert. Es wird dann dort einfach angezeigt, "wählen Sie hier aus diesen drei Versandarten" etc.

Ist der Content dargestellt, dann ist hier erst einmal soweit alles erledigt.

4. Jetzt kann der User seine Daten über einzelne Accordions für Shipping, Address, Payment und CartSummary etc. ändern.
5. Alle Änderungen wickelt die single page application aus dem DOM heraus mittels einer eigenen kleinen JS-Bibliothek über den Ajax-Controller ab, ähnlich wie bei einer React-Anwendung, nur primitiver...
6. Der Ajax-Controller schreibt dann direkt in die tl_iso_product_collection, da er via XHR die nötigen Daten etc. erhält.
7. die Daten stehen korrekt in der tl_iso_product_collection, also meinetwegen die gewählte shipping_id und die vom User gewählte payment_id
8. nun führt der User ein Reload der Seite aus und sie wird vom FrontendModule neu aufgebaut. Also alles beginnt bei 1.

9. erstaunlicherweise werden nach diesem Reload die Daten, die bereits persistent in die tl_iso_product_collection.order geschieben waren, zurückgesetzt, ohne dass eine neue order angelegt wird. Die order-ID ist korrekt und bleibt gleich. Es wird die korrekte order aus dem vorherigen Prozess einfach überschrieben. Lediglich die Daten, die Isotope selber eingetragen hat, bleiben erhalten - also z.B. die CartItems. Wie ich festgestellt habe, erfolgt dieses Zurücksetzen und Überschreiben durch meinen Aufruf von Isotope::getCart() im FrontendModul - also im Schritt 2.

Frage: Was muss ich beachten, damit der bereits existierende Cart (genauer die zugehörige Order) beim Aufruf von Isotope:getCart() nicht überschrieben oder zurückgesetzt wird?

Über ein paar Tipps würde ich mich freuen....

Grüße vom Theo

das kann ich dir leider nicht einfach so beantworten, da müsstest du den bestehenden Code lesen und ggf. nachbauen.

Danke @andreas,

das dachte ich mir schon, - und es ist natürlich auch verständlich!

Ich werde mal versuchen, mich in die ca. 200 Klassen und 30 Interfaces von Isotope etwas mehr einzuarbeiten. :D

Dennoch vielen Dank!