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
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
Lesezeichen