Ich habe die oxarticles-Klasse erweitert, sodass einem Artikel bestimmte Optionen zugeordnet sind (sind jeweils ein Objekt, das von oxbase erbt). Wenn ein Benutzer nun diesen Artikel in den Warenkorb legt, hat er bestimmte Optionen ausgewählt, die nur eine Teilmenge von den insgesamt möglichen Optionen ist.
Diese Optionen verändern neben dem Preis auch einige weitere, eigene, Eigenschaften des Artikels. Meine Frage ist nun, wie ich diesen “Zustand” des Artikels am besten durch den Bestellprozess ziehe.
Muss ich nun für jede Option hidden-Formularfelder erzeugen und dann immer den Artikel neu zusammenstricken (und prüfen, ob da nichts manipuliert wurde), oder kann ich diese Daten irgendwo elegant ablegen? Es können durchaus auch mal 30 Optionen sein, die je 5-10 Eigenschaften haben, die ich mitschleifen muss.
Hallo,
ich weiß das ist ein bisschen blöd immer wieder Werbung zu machen aber auch hier möchte ich die beiden Produkte von mir vorstellen die genau das machen was du benötigst.
Die Persparams hatte ich gar nicht mehr auf dem Schirm. Wenn ich das richtig im Kopf habe, wird das persparam Array ja eh serialisiert in die DB gelegt. Sollte genau das machen was ich brauche.
[QUOTE=OXID-Design;177868]Hallo,
ich weiß das ist ein bisschen blöd immer wieder Werbung zu machen aber auch hier möchte ich die beiden Produkte von mir vorstellen die genau das machen was du benötigst.
Ich habe die Situation stark vereinfacht dargestellt. Die Optionen können sich je nach Kategoriepfad ändern, sind teilweise untereinander inkompatibel oder erfordern einander und beeinflussen sich möglicherweise auch gegenseitig. Ich bezweifle doch stark, dass das mit den beiden Modulen abbildbar ist.
Trotzdem danke für die Links, ist in Zukunft vielleicht nützlich.
Erstens kann man mit der Konfigurationen Ebenen nachbilden, ähnlich wie die Shop-Kategorien und zweitens können Einzelner Konfigurationen und unterebnen (Preise) sich gegenseitig beeinflussen.