Entwicklung
Architektur in Kürze
Das Plugin bringt kein eigenes Datenmodell mit. Es hängt sich an den Artikel und prüft an vier Stellen dieselbe Frage: Darf dieser Kunde diesen Artikel haben?
Die Regel selbst liegt in einer einzigen Klasse, Content\CustomProduct\CustomerAssignment. Seite und Warenkorb rufen sie beide auf — genau deshalb kann eine Variante, die die Seite ausliefert, im Warenkorb nicht plötzlich verschwinden.
Baustein | Klasse | Aufgabe |
|---|---|---|
Zugriffsregel |
| Beantwortet die Zugriffsfrage — die einzige Stelle mit der Logik |
Seite & Suche |
| Detailseite, Suche und Suggest; Umleitung auf eine zugängliche Variante |
Warenkorb |
| Entfernt fremde Positionen, korrigiert den Child-Count |
Store-API |
| Liste der eigenen Artikel |
Cache |
| Dekoriert die Route, cacht pro Kunde |
Artikelfelder |
| Laufzeitfelder |
Abhängigkeiten
Paket | Rolle |
|---|---|
| Plattform |
| Basis für CMS-Element und Storefront-JS |
| Lizenzprüfung im Plugin-Lebenszyklus |
|
|
| Filter und Antwortverarbeitung |
Die Kopplung an BusinessTransactions ist eng: Das Twig-Element erweitert @BusinessTransactions/storefront/element/transactions_base_element.html.twig, und das Storefront-Plugin importiert seoUrls sowie ProcessTransactionResponseFunction daraus.