Auswahllisten relational abbilden

Deutsches Forum
1

Ich mag’ ja die Auswahllisten, aber dass die Implementierung nicht als relationale Datenbank gelöst ist, macht mir gearde zu schaffen.

Worum geht es. Ich habe in den Auswahllisten z.B. Druckpreise, die je nach Art des Aufdrucks unterschiedlich sind. Also “Ätzung” kostet 0,20€, “Lasergravur” 0,32€, usw.
So weit, so gut. Allerdings ist der Aufdruck nicht in einer gesonderten Tabelle erfasst, sondern steht (mit allen möglichen Aufdrucken des Artikels) in der oxselectlist und ist mit dem jeweiligen Artikel über die oxobject2selectlist verknüpft.

Wenn ich jetzt den Preis für die “Lasergravur” von 0,32€ auf 0,28€ (bei allen Artikeln) ändern muss, ist das zwar etwas gefummel, aber es geht. Ok, auch nur weil ich die Datenbank über eine andere relationale Datenbank gefüttert habe und Lasergravur dadurch auch immer wirklich Lasergravur heißt und niemals Laser-Gravur oder lasergravur oder andere möglichen Schreibweisen.

Das wirkliche Problem ist jetzt aber eigentlich, dass es mehrere verschiedene Lasergravuren gibt, alle mit unterschiedlichen Preisen. Jetzt soll ich eine Lasergravur (temporär) vom Preis reduzieren. Von 0,32€ auf 0,28€. Allerdings gibt es bereits eine andere Lasergravur mit dem Preis. Wenn ich das jetzt per Suchen und ersetzen mache, verliere ich die Info, welche Lasergravur der Artikel jetzt eingentlich hat. Oder anders gesagt: wenn ich den Preis von 0,28€ wieder auf 0,32€ erhöhen soll, muss ich wieder alle Vorkommen verändern und damit auch die Artikel, die eigentlich nur 0,28€ Aufschlag bekommen sollen.

Ich hoffe, das war halbwegs verständlich. Gibt es hierfür einen Ansatz/ein Modul?

Ich habe zwar schon eine Idee, wie ich das geschickt ändern kann, aber da steckt schon etwas Arbeit drin und warum soll man das Rad zweimal erfinden :}

Jetzt habe ich folgende Herausforderung:

2

Also eigentlich sind die Auswahlisten ein Besipiel für eine relationale Beziehung.

Du kannst diese mit einer Datumseingabe erweitern und die Preisausgabe entsprechend manipulieren.

1 Like
3

hallo matze,

ja, hier produktkinfigurator, aufbau ist ähnlich wie die auswahllisten. mit dem modul kannst du sogar die gravur texte mitberechnen (nach anzahl buchstaben usw. usf) die kunden dort frontend eingeben können. einfach bisschen damit spielen, möglichkeiten sind viel.

die administratiionsbereich im demo shop ist frei zugänglich und das modul findest du bei mir im shop.

4

@rubbercut: Du hast natürlich recht, die Auswahllisten werden relational mit den Artikeln verknüpft. So weit, so gut. Allerdings sind die Auswahllisten selbst ja nicht weiter verschachtelt. Sprich in der oxvaldesc steht z.b.: “mit Liebe!P!0.1__@@ohne Liebe__@@”. Wenn ich das ändere, ändern sich natürlich auch alle Artikel, die damit verknüpft sind. Allerdings stehen in meinen Auswahllisten ja mehrere verschiedene Druckarten und Preise (weil auch nicht jeder Artikel mit jeder Druckmethode bedruckbar ist). Im Prinzip hätte ich gerne eine weitere Tabelle mit den Möglichen Druckarten/Preisen und in den Auswahllisten würde ich dann darauf referenzieren.
Bsp: oxselectlist-> oxvaldesc="[id=mit Liebe][id=ohne Liebe]" und dann eine andere Tabelle id=“mit Liebe” Preis=“0.1”, id=“ohne Liebe” Preis=“0”
Wenn ich mir das so anschaue wäre das noch nicht einmal eine relationale Beziehung, sondern es müßte lediglich möglich sein, in der oxvaldesc einen/mehrere Fremdschlüssel auf eine andere Tabelle anzugeben.

@OXID-Design: wenn ich es richtig sehe, besteht mit Deinem Modul das gleiche Problem, die Felder sind z.B. in der Profilfarbe hinterlegt, aber auch hier habe ich Probleme, wenn ich verschiedene Werte in einer Auswahlliste mischen möchte!? Egal, ich kenne meinen Kunden, das Modul ist ihm sicher zu teuer :face_with_symbols_over_mouth:

5

Klar, die Verarbeitung musst erweitern. __@@ ist der Trenner. Wir haben das in einem Stempelkonfigurator gemacht. Ist nicht schwer.

6

nein, ganz sicher nicht. es gibt felder wo die preise dynamisch berechnet werden. aber gut.

7

Ok, vielleicht mache ich einen Denkfehler.
Sagen wir ich habe die Artikel A, B und C und die Druckmöglichkeit X, Y und Z
Für jeden Artikel habe ich eine passende Auswahlliste.
Artikel A kann mit X und Y bedruckt werden
Artikel B kann mit X und Z bedruckt werden
Artikel C kann mit Y und Z bedruckt werden
Möchte ich jetzt den Druckpreis für X ändern, muss ich die Auswahlliste für den Artikel A und B anpassen. Richtig? Ich kann nicht global den Druckpreis für X ändern!?

8

die auswahllisten funktionieren doch so. ich erstelle eine liste und kann dazu mehrere artikel zuordnen. ändere ich meine liste, sind alle artikel davon betroffen die ich zuvor zugeordnet habe. das ist die logik dahinter.

9

@OXID-Design ja, so die Theorie. Allerdings habe ich bei vielen Artikeln ja unterschiedliche Kombinationen von Auswahlmöglichkeiten. So gibt es manche Artikel in rot, grün und blau. Andere nur in rot und blau (wären jetzt zwei Auswahllisten zum anlegen). Klingt aber nur im Beispiel gut, ich habe in der Realität ca. 25-30 Druckmöglichkeiten, von denen jeder Artikel ca. 3-5 hat. Da ist es einfacher, pro Artikel eine Auswahlliste anzulegen (Stichwort: kombinatorische Explosion).
Deshalb suche ich quasi eine Möglichkeit, hier auf die verschiedenen (Basis) Druckmöglichkeiten zu verweisen. Hach, ist echt knifflig das zu beschreiben.

10

Ich glaube, ich verstehe die Verwirrung.
In OXID werden die Auswahllisten mit allen Auswahlmöglichkeiten als ein “Gesamtes” konfiguriert, d.h. es gibt keine getrennten Entities für Auswahllisten und einzelne Auswahlmöglichkeiten.
Das ergibt bei einigen Geschäftsmodellen mehr Sinn als bei anderen und ich glaube, dass es in euren Shop eher weniger Sinn ergibt.

Ihr verkauft im Endeffekt keine Varianten von einem Produkt, sondern eine Kombination aus einem Produkt und eurer Dienstleistung. Das wäre ein Fall für ein Produkt Bundle oder Set.

1 Like
11

jetzt habe ich kapiert. ohne eine eindeutige id, für jeder einzelne option, wie in meinem modul der fall ist wird das eine reine rumfummelerei. aber möglich ist natürlich alles.

1 Like
12

Danke.
Die Syntax der oxvaldesc so zu erweitern, dass ich hier auf eine id einer gesonderten Liste verweise wäre demnach doch eine sinnvolle Ergänzung.
Also den Trenner __@@ beibehalten und mittels gesondertem Tag auf einen Fremdschlüssel hinweisen. Dann muss ich noch die Anpassungen an der Stelle vornehmen, an der die Auswahllisten zusammengebaut werden und… das sollte es auch “schon” gewesen sein :thinking:

13

auch das habe ich schon gelöst und das modul liegt hier bei mir irgendwo in der ecke. ja, es funktioniert schon aber es geht definitiv besser, wenn man das ganze anständig neu schreibt, ohne oxvaldesc und den komischen trennern. die auswahlisten sind einfach gehalten und es ist auch gut so. wenn du trotzdem an dem alten modul rumfummeln willst, sag bescheid.

was hältst du von der idee die marat gerade vorgeschlagen hat.

14

@OXID-Design mit dem bundle oder set? muss ich mir offen gesagt mal anschauen…

15

gravur bedeutet aber auch kunden können individuelle texte eingeben, wie willst du das denn lösen?

16

Musst Du nicht. Schau Dir selectlist_main::save() an. Hier kannst die Speicherung erweitern. Und dann wirf einen Blick in oxutils::_fillExplodeArray(),

17

@rubbercut gute Info, da gucke ich mal :slight_smile:

@OXID-Design: garnicht. Der Druckpreis bezieht sich immer auf die maximal mögliche Druckfläche, die Daten der Kunden gehen dann im Haus in die Druckvorstufe, Kunde bekommt einen Korrekturabzug. Hat auch etwas den Hintergrund, dass viele (Firmen-)Kunden die als Subnternehmer arbeiten (also Filialen, etc.) nicht wirklich über die richtige CI/CD des Unternehmens unterrichtet sind.

Auf jeden Fall möchte ich mich schon einmal bei allen für die schnelle Erleuchtung bedanken.
Nur so als Info: bei den Artikel parse ich normalerweise die Daten vom Hersteller (in der Regel mit vielen Inkonsistenzen und schlecht aufbereitet), überführe die in eine relationale Datenbank und schreibe daraus wieder die Einträge für OXID

18

na dann viel erfolg!

1 Like
19

Kleines Update.
Ich habe das Problem jetzt erst einmal so gelöst, dass ich in einer neuen Tabelle erst einmal alle unterschiedlichen Vorkommen von Eigenschaft und Preis sammle. Danach lasse ich eine Tabelle/Formular ausgeben, in dem ich die Preise dann ändern kann. Besser, als jedesmal per Hand den SQL-Befehl eintippen zu müssen.

Aufpassen:

  • momentan muss ich noch selbst darauf achten, dass ich nicht aus versehen zwei (eigentlich unterschiedliche) Preise gleich setzte - dann könnte ich nicht mehr differenzieren.
  • beim Ändern der Preise gab es teilweise seltsame Ergebnisse, weil z.B. bei 0,40€ der Float-Wert 0,4 ist und wenn ich dann 0,4 durch 0,38 ersetzen möchte, wird aus 0,42 dann 0,382
  • Das Aufbauen der Liste dauert je nach Umfang der Einträge und Server doch einen Moment. Deshalb werde ich das Ändern der Einträge á la AJAX machen.
  • Das ganze in ein Modul stopfen wäre dann noch der nächste Schritt. Wenn ich mal Zeit habe :-/
20

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.