nicht angemeldet
verschiedene Rabattgruppen im Online-Shop
Hallo!
Mal wieder ne Programmiertechnik-Frage von mir ;-) Ich überlege gerade, wie ich verschiedene Rabattgruppen in einen Online-Shop integrieren kann. Z.B. gibt es das öfter in Firmen, das je nach Umsatz die Kunden in bestimmte Rabatt-Klassen eingeteilt werden. Problem ist, das ist Prozentual nicht immer gleich, sondern es gibt dann halt 7 Preise bei einem Produkt.
Wie macht man das sinnvollerweise? Natürlich muß man sich einloggen, dann hat man in der Kundentabelle die entsprechende Rabattgruppe der Kunden gespeichert, und dann? Die Preise stehen dann ja in einer anderen Spalte, sollte man da die SQl-Abfrage dynamisch zusammensetzen? Wie würdet Ihr das machen?
Viele Grüße
Andreas
-
Halihallo Andreas
Mal wieder ne Programmiertechnik-Frage von mir ;-) Ich überlege gerade, wie ich verschiedene Rabattgruppen in einen Online-Shop integrieren kann. Z.B. gibt es das öfter in Firmen, das je nach Umsatz die Kunden in bestimmte Rabatt-Klassen eingeteilt werden. Problem ist, das ist Prozentual nicht immer gleich, sondern es gibt dann halt 7 Preise bei einem Produkt.
Grundlegende Frage: Sind die Rabatt-Klassen auf einen Artikel festlegbar, oder hängen die mit dem Kunden zusammen? - Z. B. Kunde xyz erhält für alle Artikel global 10% Rabatt, oder Kunde xyz hat die Rabattklasse 2, was bei Artikel 15 zur Folge hat, dass er mit nur 10 EUR verrechnet wird...???
Willst du die Rabattklasse wirklich einem Kunden zuordnen und dann für _jeden_ einzelnen Artikel die Preise/Rabattklasse setzen? - Wäre es nicht viel einfacher, wenn man einen "globalen" Kundenrabatt in Prozenten formuliert?
Nach welchem Kriterium wird der Kunde in eine bestimmte Rabattklasse eingeordnet?Wie macht man das sinnvollerweise? Natürlich muß man sich einloggen, dann hat man in der Kundentabelle die entsprechende Rabattgruppe der Kunden gespeichert, und dann? Die Preise stehen dann ja in einer anderen Spalte, sollte man da die SQl-Abfrage dynamisch zusammensetzen? Wie würdet Ihr das machen?
Wenn ich deine Idee richtig verstanden habe, würde ich folgendes vorschlagen:
Die Tabelle Artikel enthält gar keine Preisangaben. Diese stehen in einer anderen Tabelle 'Price':
Tabelle Price
ArticleID (primary)
PriceClassID (primary)
AbsolutePriceTabelle Client
ClientID
Name
PriceClassIDWenn man nun den Preis für einen Artikel auslesen will:
SELECT P.AbsolutePrice FROM Price AS P, Client AS C WHERE P.ArticleID='xxx' AND C.ClientID='xxx' AND P.PriceClassID=C.PriceClassID
oder so ähnlich...
Viele Grüsse
Philipp
-
Moin!
Grundlegende Frage: Sind die Rabatt-Klassen auf einen Artikel festlegbar, oder hängen die mit dem Kunden zusammen? - Z. B. Kunde xyz erhält für alle Artikel global 10% Rabatt, oder Kunde xyz hat die Rabattklasse 2, was bei Artikel 15 zur Folge hat, dass er mit nur 10 EUR verrechnet wird...???
Wie gesagt, es gibt 7 Rabattklassen für jedes Produkt, die Kunden werden dann einer dieser 7 Klassen zugeordnet. Wenn die Rabattklassen nur jeweils einen bestimmten Prisabschlag in % bvedeuteten, hätte ich das Problem nicht, denn diese Prozente kann man einfach bei der Ausgabe berücksichtigen. Pordukt XY hat also 7 Preise, einen für jede Rabattgruppe. Die Preise werden alle einzeln festgelegt.
Willst du die Rabattklasse wirklich einem Kunden zuordnen und dann für _jeden_ einzelnen Artikel die Preise/Rabattklasse setzen? - Wäre es nicht viel einfacher, wenn man einen "globalen" Kundenrabatt in Prozenten formuliert?
Ja, einfacher wäre es, aber es ist nicht so.
Nach welchem Kriterium wird der Kunde in eine bestimmte Rabattklasse eingeordnet?
nach umsatz, aber nicht automatisch, sondern durch einen Mitarbeiter eingestuft, je mehr Umsatz durch den Kunden, desto besser die Rabattklasse.
Die Tabelle Artikel enthält gar keine Preisangaben. Diese stehen in einer anderen Tabelle 'Price':
Tabelle Price
ArticleID (primary)
PriceClassID (primary)
AbsolutePriceTabelle Client
ClientID
Name
PriceClassIDNö, ich habe
Tabelle Article
ArticleID (primary)
Beschreibung
...
PriceClass1
PriceClass2
...
PriceClass7Tabelle Client
ClientID
Name
PriceClassIDWenn man nun den Preis für einen Artikel auslesen will:
SELECT P.AbsolutePrice FROM Price AS P, Client AS C WHERE P.ArticleID='xxx' AND C.ClientID='xxx' AND P.PriceClassID=C.PriceClassID
waren das nicht die tötlichst unperformantesten Joins? ;-)
oder so ähnlich...
SELECT PriceClassID FROM Client WHERE ClientID='xyx'
$preisklasse="PriceClass".$sql_result;
SELECT $preisklasse FROM Article WHERE ArticleID='xxx'
So in etwa, aber irgendwie sehr unschön, oder?
Viele Grüße
Andeas-
Halihallo again ;)
Wie gesagt, es gibt 7 Rabattklassen für jedes Produkt, die Kunden werden dann einer dieser 7 Klassen zugeordnet. Wenn die Rabattklassen nur jeweils einen bestimmten Prisabschlag in % bvedeuteten, hätte ich das Problem nicht, denn diese Prozente kann man einfach bei der Ausgabe berücksichtigen. Pordukt XY hat also 7 Preise, einen für jede Rabattgruppe. Die Preise werden alle einzeln festgelegt.
Ach so, ich dachte das mit '7' wäre ein Beispiel. Aber wenn's dann genau sieben Klassen gibt (weiter unten...)
Nach welchem Kriterium wird der Kunde in eine bestimmte Rabattklasse eingeordnet?
nach umsatz, aber nicht automatisch, sondern durch einen Mitarbeiter eingestuft, je mehr Umsatz durch den Kunden, desto besser die Rabattklasse.OK. Klingt sehr vernümftig... Dachte, dass dies auch automatisiert ist, dann wäre der Algorithmus noch interessant gewesen, da dann die Sache vielleicht auch anders umsetzbar wäre.
[...]
Nö, ich habe
Tabelle Article
ArticleID (primary)
Beschreibung
...
PriceClass1
PriceClass2
...
PriceClass7Warum sagst du das denn nicht gleich ;)
Aber irgendwie kommt mir das eh bekannt vor, nicht??? :-)SELECT P.AbsolutePrice FROM Price AS P, Client AS C WHERE P.ArticleID='xxx' AND C.ClientID='xxx' AND P.PriceClassID=C.PriceClassID
waren das nicht die tötlichst unperformantesten Joins? ;-)
hehe... Kein Kommentar ;-)
Für alle anderen im Forum, das war ein insider ;)oder so ähnlich...
SELECT PriceClassID FROM Client WHERE ClientID='xyx'$preisklasse="PriceClass".$sql_result;
SELECT $preisklasse FROM Article WHERE ArticleID='xxx'
So in etwa, aber irgendwie sehr unschön, oder?
Eben ;-))))
Aber nu mal im Ernst: Ich glaube kaum, dass es eine andere Möglichkeit gäbe. Entweder du musst den Query dynamisch generieren, oder die Daten müssen in einer anderen Tabelle stehen. Was anderes gibt's IMHO nicht (sorry, aber auch Scotty kann die Gesetze des Universums nicht ändern ;-)).
Und um den Kreis zu schliessen: In der Language-Angelegenheit geht's ja auch nicht anders.
süsse Grüsse
Philipp
-
Heyho!
Ach so, ich dachte das mit '7' wäre ein Beispiel. Aber wenn's dann genau sieben Klassen gibt (weiter unten...)
Wars auch, ist aber keine Zahl > 12!
OK. Klingt sehr vernümftig... Dachte, dass dies auch automatisiert ist, dann wäre der Algorithmus noch interessant gewesen, da dann die Sache vielleicht auch anders umsetzbar wäre.
Hm? Wäre vielleicht mal eine Überlegung Wert! Aber wenn Du das automatisierst, wie Du es wahrscheinlich vor hättest(bei JEDER Abfrage die Umsätze abfragen?!), dann wird das wieder sehr umständlich, oder? Ich würde da wennliebr regelmäßig per Cron ein Script drüberlaufen lassen, welches die Einteilungen vornimmt! Das hat mit dem restlichen Traffic... nichts zu tun, und nimmt schonmal etwas Arbeit ab!
Warum sagst du das denn nicht gleich ;)
Hab ich doch ;-)))
Aber irgendwie kommt mir das eh bekannt vor, nicht??? :-)
Jajaja, bin halt noch nie in eine RDBMS verliebt gewesen...
waren das nicht die tötlichst unperformantesten Joins? ;-)
hehe... Kein Kommentar ;-)Für alle anderen im Forum, das war ein insider ;)
na diesmal haste ja noch einen drauf gesetzt, wenn es wenigstens LEFT JOINS oder sowas wären, aber solche Joins (habe ich mir in diesem Forum sagen lassen) sind die von der schlimmsten Sorte, dei man nur verwenden sollte, wenn man auch _genau_ das, was da erzeugt wird haben will!
Eben ;-))))
tja...
Aber nu mal im Ernst: Ich glaube kaum, dass es eine andere Möglichkeit gäbe. Entweder du musst den Query dynamisch generieren, oder die Daten müssen in einer anderen Tabelle stehen. Was anderes gibt's IMHO nicht (sorry, aber auch Scotty kann die Gesetze des Universums nicht ändern ;-)).
Stimmt..., naja, ein Versuch wars Wert ;-)
Und um den Kreis zu schliessen: In der Language-Angelegenheit geht's ja auch nicht anders.
Jep!
-- Andreas
-
Ja sag amol, musst noch nicht schlafen??? <-- Begrüssung!!! :) -->
OK. Klingt sehr vernümftig... Dachte, dass dies auch automatisiert ist, dann wäre der Algorithmus noch interessant gewesen, da dann die Sache vielleicht auch anders umsetzbar wäre.
Hm? Wäre vielleicht mal eine Überlegung Wert! Aber wenn Du das automatisierst, wie Du es wahrscheinlich vor hättest(bei JEDER Abfrage die Umsätze abfragen?!),
Erst Moralikus und jetzt auch noch Gedankenleser??? - Du wirst mir langsam unheimlich ;-)))
Und das schlimme ist: Du hast sogar recht ;-)
Ich kann auf meinem Webserver halt keine Cron's definieren ;-(((
Aber nur deshalb! - Versprochen! ;-)dann wird das wieder sehr umständlich, oder? Ich würde da wennliebr regelmäßig per Cron ein Script drüberlaufen lassen, welches die Einteilungen vornimmt! Das hat mit dem restlichen Traffic... nichts zu tun, und nimmt schonmal etwas Arbeit ab!
Wenn der Webserver das Erlaubt, auf jeden Fall! - Sowas schreit fast nach einem Cron-job. Wär ja blöd wegen jedem Euro gleich die ganze Geschichte neu zu berechnen...
Warum sagst du das denn nicht gleich ;)
Hab ich doch ;-)))nix da! - Von Schema hab ich nix g'sehn!!!
Aber irgendwie kommt mir das eh bekannt vor, nicht??? :-)
Jajaja, bin halt noch nie in eine RDBMS verliebt gewesen...***arghhh***, 1:0 für dich ;-)
waren das nicht die tötlichst unperformantesten Joins? ;-)
hehe... Kein Kommentar ;-)Für alle anderen im Forum, das war ein insider ;)
na diesmal haste ja noch einen drauf gesetzt, wenn es wenigstens LEFT JOINS oder sowas wären, aber solche Joins (habe ich mir in diesem Forum sagen lassen) sind die von der schlimmsten Sorte, dei man nur verwenden sollte, wenn man auch _genau_ das, was da erzeugt wird haben will!
He? - Also das bedarf einer Erklärung! - Was soll an dem Query nicht gut sein??? - Natural Joins sind am Schnellsten! - Kannst du mal die URL von dem Thread posten? - Würd mich interessieren.
Viele nächtliche Grüsse
Philipp
-
Hallo!
Erst Moralikus und jetzt auch noch Gedankenleser??? - Du wirst mir langsam unheimlich ;-)))
man tut was man kann!!!
Und das schlimme ist: Du hast sogar recht ;-)
Ich kann auf meinem Webserver halt keine Cron's definieren ;-(((schlecht, schlecht, schlecht! Ist ne feine Sache!
Aber nur deshalb! - Versprochen! ;-)
hoffen wirs!
Wenn der Webserver das Erlaubt, auf jeden Fall! - Sowas schreit fast nach einem Cron-job. Wär ja blöd wegen jedem Euro gleich die ganze Geschichte neu zu berechnen...
gut - Du bist mal meiner Meinung!
nix da! - Von Schema hab ich nix g'sehn!!!
Das Schema war hinter meinen nicht mehr alszu klaren Worten versteckt, ein bisschen mitdenken darf man hier wohl noch erwarten, oder?
Aber irgendwie kommt mir das eh bekannt vor, nicht??? :-)
Jajaja, bin halt noch nie in eine RDBMS verliebt gewesen...***arghhh***, 1:0 für dich ;-)
1:0? 7:2 wüde ich sagen ,-)))
He? - Also das bedarf einer Erklärung! - Was soll an dem Query nicht gut sein??? - Natural Joins sind am Schnellsten! - Kannst du mal die URL von dem Thread posten? - Würd mich interessieren.
Ups, wenn Du schon so ankommst wird das wohl falsch sein, Du bist der DB-Spezialist von uns beiden - nach einer schlauchenden Suche in den unendlichen Tiefen des Self-Archiv habe ich glaub ich den Beitrag ausgegraben, den ich meinte - aber vielleicht passt das auch gar nicht, les´ selbst: http://forum.de.selfhtml.org/archiv/2002/4/8632/#m48848
Grüße
Andreas-
Halihallo Andreas
Wenn der Webserver das Erlaubt, auf jeden Fall! - Sowas schreit fast nach einem Cron-job. Wär ja blöd wegen jedem Euro gleich die ganze Geschichte neu zu berechnen...
gut - Du bist mal meiner Meinung!Ach was! - Ist doch nicht das erste mal! - Etwas mehr Selbstsicherheit (die hättest du auch verdient!)! -> Mail an dich wegen SQL-Statements und Language noch nicht gelesen??? - Da hast DU mich ja eines besseren gelehrt (und das nur als Beispiel)!
nix da! - Von Schema hab ich nix g'sehn!!!
Das Schema war hinter meinen nicht mehr alszu klaren Worten versteckt, ein bisschen mitdenken darf man hier wohl noch erwarten, oder?'tschuldige, 'tschuldige, ja, das darf man ;)
Aber irgendwie kommt mir das eh bekannt vor, nicht??? :-)
Jajaja, bin halt noch nie in eine RDBMS verliebt gewesen...***arghhh***, 1:0 für dich ;-)
1:0? 7:2 wüde ich sagen ,-)))mal nachzählen... **arghh2**, hast schon wieder gewonnen ;-)
He? - Also das bedarf einer Erklärung! - Was soll an dem Query nicht gut sein??? - Natural Joins sind am Schnellsten! - Kannst du mal die URL von dem Thread posten? - Würd mich interessieren.
Du bist der DB-Spezialist von uns beiden
Scheint aber eher das Gegenteil zu sein!
nach einer schlauchenden Suche in den unendlichen Tiefen des Self-Archiv habe ich glaub ich den Beitrag ausgegraben, den ich meinte - aber vielleicht passt das auch gar nicht, les´ selbst: http://forum.de.selfhtml.org/archiv/2002/4/8632/#m48848
Der passt ganz genau. Ich hatte gedacht, dass der Statement-Optimizer dies automatisch so macht, aber, wenn's dann Sven meint... Ich glaube eher ihm, da ich selber nicht genug über die Optimierungsmechanismen informiert bin. Mit den Joins hat er recht, das ich sicher gut, aber ob mysql das (mit einem so eindeutigen Query) nicht automatisch macht??? - Müsste ich mal nachlesen.
Da habt ihr mich (wieder! - siehst!) eines besseren belehrt. Danke an dieser Stelle.
Viele Grüsse
Philipp
PS: </?m=84403&t=14985> gesehen?
-
hi!
Der passt ganz genau. Ich hatte gedacht, dass der Statement-Optimizer dies automatisch so macht, aber, wenn's dann Sven meint... Ich glaube eher ihm, da ich selber nicht genug über die Optimierungsmechanismen informiert bin. Mit den Joins hat er recht, das ich sicher gut, aber ob mysql das (mit einem so eindeutigen Query) nicht automatisch macht??? - Müsste ich mal nachlesen.
Ich hab wirklich keine Ahnung ;-))) Habe ich nur damals gelesen und behalten. Kenne mich selbst aber nicht aus.
Aber wo liest Du sowas nach?PS: </?m=84403&t=14985> gesehen?
Jajaja, daher auch der andere Thread, komme von einem Problem zum nächsten... Aber wenigstens dieses scheint ja gelöst, aber man kommt ja hier zu nix ... *ggg*
-- Andreas
-
Halihallo again ;)
Der passt ganz genau. Ich hatte gedacht, dass der Statement-Optimizer dies automatisch so macht, aber, wenn's dann Sven meint... Ich glaube eher ihm, da ich selber nicht genug über die Optimierungsmechanismen informiert bin. Mit den Joins hat er recht, das ich sicher gut, aber ob mysql das (mit einem so eindeutigen Query) nicht automatisch macht??? - Müsste ich mal nachlesen.
Habe ich nur damals gelesen und behalten. Kenne mich selbst aber nicht aus.
Aber wo liest Du sowas nach?Google ;-)
Hab schon danach gesucht, bin jedoch noch zu keinem Resultat gekommen (was darauf schliessen lässt, dass ich entweder google nicht optimal benutzen kann, oder dass es wirklich keinen Optimizer für sowas gibt [ach herje, mir wird übel, alle Queries überarbeiten...] )...PS: </?m=84403&t=14985> gesehen?
Jajaja, daher auch der andere Thread, komme von einem Problem zum nächsten... Aber wenigstens dieses scheint ja gelöst, aber man kommt ja hier zu nix ... *ggg*mäno ;-)
Viele Grüsse
Philipp
-
Halihallo nochmals (nur kurz)
Der passt ganz genau. Ich hatte gedacht, dass der Statement-Optimizer dies automatisch so macht, aber, wenn's dann Sven meint... Ich glaube eher ihm, da ich selber nicht genug über die Optimierungsmechanismen informiert bin. Mit den Joins hat er recht, das ich sicher gut, aber ob mysql das (mit einem so eindeutigen Query) nicht automatisch macht??? - Müsste ich mal nachlesen.
Habe ich nur damals gelesen und behalten. Kenne mich selbst aber nicht aus.
Aber wo liest Du sowas nach?Google ;-)
Hab schon danach gesucht, bin jedoch noch zu keinem Resultat gekommen (was darauf schliessen lässt, dass ich entweder google nicht optimal benutzen kann, oder dass es wirklich keinen Optimizer für sowas gibt [ach herje, mir wird übel, alle Queries überarbeiten...] )...Juhuiiii, jetzt bin ich gerettet:
http://www.cs.ait.ac.th/laboratory/database/manual/manual_MySQL_Optimization.shtml"All constant tables are read first, before any other tables in the query. A constant table is:
- A table that is used with a WHERE clause on a UNIQUE index, or a PRIMARY KEY, where all index parts are used with constant expressions and the index parts are defined as NOT NULL."Sollte für die ärgsten Performance Probleme schon mal genügen... Aber ihr habt recht: Natural Joins (so heissen die, hoffentlich) werden nicht automatisch dahingehend optimiert, wie in Svens Beispiel.
Viele Grüsse
Philipp
-
Hi!
Juhuiiii, jetzt bin ich gerettet:
http://www.cs.ait.ac.th/laboratory/database/manual/manual_MySQL_Optimization.shtml"All constant tables are read first, before any other tables in the query. A constant table is:
- A table that is used with a WHERE clause on a UNIQUE index, or a PRIMARY KEY, where all index parts are used with constant expressions and the index parts are defined as NOT NULL."
Naja, auch wenn ich das nicht wirklich verstehe, Glückwunsch zum moralischen Erfolg!
Sollte für die ärgsten Performance Probleme schon mal genügen... Aber ihr habt recht: Natural Joins (so heissen die, hoffentlich) werden nicht automatisch dahingehend optimiert, wie in Svens Beispiel.
Aber wie Sven mnir kürzlich klargemacht hat - wenn man keine Performance.-Probleme hat braucht man ja eigentlich nichts zu ändern - aber ich gebe zu - die Versuchung ist groß, man will ja keine schlechte DB haben...
Nochmal zu dem OOP Thread:
getArticles
foreach (@articles) { # für jeden Artikel in der Session mach...
- $tmp = neue Instanz von Artikel...
- die Instanz in ein Array packen...
}
return InstanceArray; # das "InstanzenArray" zurückgebenIch verstehe das nicht. Wie kann ich einen Array mit instanzen erstellen? Ich kann mir das leider nicht vorstellen, der Rest funktioniert jetzt(Warenkorb-Klasse, bekome Gesamtanzahl, Summe...) aber leider habe ich das mit der Artikel-Klasse noch nicht im Griff.
Ich hatte mal folgendes versucht(in der Warenkorb-Klasse):
// einfach den Warenkorb-Array aus der Session ausgeben
function artikel(){
return $_SESSION["warenkorb"];}
$artikels = $wb -> artikel;
echo "Artikel1: ".var_dump($artikels);Da kommt aber nx an : NULL!
Naja, ich weiß, ich stelle mich ziemlich doof an, verstehe das auch nicht, bin sonst auch nicht soooo schwer von Begriff!
Grüße
Andreas-
Halihallo
kurz vor dem erholsamen Schlaf...
Juhuiiii, jetzt bin ich gerettet:
http://www.cs.ait.ac.th/laboratory/database/manual/manual_MySQL_Optimization.shtml"All constant tables are read first, before any other tables in the query. A constant table is:
- A table that is used with a WHERE clause on a UNIQUE index, or a PRIMARY KEY, where all index parts are used with constant expressions and the index parts are defined as NOT NULL."
Naja, auch wenn ich das nicht wirklich verstehe, Glückwunsch zum moralischen Erfolg!
Sagt etwa über die Reihenfolge aus, in welcher die Tabellen miteinander verknüft werden (also das Kreuzprodukt der Tabellen in einer temporären Tabelle gebildet wird):
Wenn man etwa folgendes hat:SELECT * FROM a, b WHERE a.primary=1 AND b.whatever='hello'
und die Spalte primary der Tabelle a UNIQUE ist bzw. der Primarykey, dann wird zuerst diese Tabelle eingelesen. Und da dann a.primary=1 logischerweise (eben wegen Primary oder UNIQUE) nur einen Record matched, wird das Kreuzprodukt viel, viel kleiner (also nicht die von Sven genannte 100*100*100... - Problematik). Das Kreuzprodukt hat dann nämlich nicht count(a.*) * count(b.*) Datensätze, sondern nur 1 * count(b.*)... Somit gibt das dann genau das selbe Ergebnis, wie Sven mit den Joins erreicht. Hoffe, dass ich das richtig und einigermassen verständlich forumieren konnte.
getArticles
foreach (@articles) { # für jeden Artikel in der Session mach...
- $tmp = neue Instanz von Artikel...
- die Instanz in ein Array packen...
}
return InstanceArray; # das "InstanzenArray" zurückgebenIch verstehe das nicht. Wie kann ich einen Array mit instanzen erstellen?
Eine Instanz ist ja nichts anderes als ein Wert... Diese kann ganz wie gehabt an ein Array gepushed werden... Da wird wohl auch mit PHP funktionieren. Also: Für jeden Artikel erstellst du eine entsprechende Artikel-Klassen-Instanz (z. B. $article = neu Artikel). Den Wert von $article fügst du ganz normal (wie eine Zahl, oder eine Variable) an das Array an und gibst dieses Zurück. Im Hauptprogramm kannst du das Array dann auslesen und z. B. über jedes Arrayelement (was ja einer Instanz der Artikel-Klasse entspricht) iterieren...
Ich hatte mal folgendes versucht(in der Warenkorb-Klasse):
// einfach den Warenkorb-Array aus der Session ausgeben
function artikel(){
return $_SESSION["warenkorb"];
}
$artikels = $wb -> artikel;
echo "Artikel1: ".var_dump($artikels);Da kommt aber nx an : NULL!
ist die Funktion artikel denn in der Klasse definiert (sorry, dumme Frage)? (im Beispiel ist ja kein class drumm herum, deshalb die Frage). Also, wenn die Funktion in der Klasse für $wb definiert ist, sollte das meines Erachtens schon funktionieren.
Kurze Statusfrage: Hier hast du ja keine Artikelklasse verwendet. Ist das nur ein Test, ob die Basis funktioniert? - Wenn du die Artikelklasse implementieren willst, musst ja für jedes Arrayelement von $_SESSION["warenkorb"] eine eigenständige Instanz der Artikel-Klasse erstellen und das Array aller erstellen Instanzen zurückgeben.
Viele Grüsse
Philipp
-
Moin!
kurz vor dem erholsamen Schlaf...
ich jetzt kurz dahinter ;-)
Eine Instanz ist ja nichts anderes als ein Wert... Diese kann ganz wie gehabt an ein Array gepushed werden... Da wird wohl auch mit PHP funktionieren. Also: Für jeden Artikel erstellst du eine entsprechende Artikel-Klassen-Instanz (z. B. $article = neu Artikel). Den Wert von $article fügst du ganz normal (wie eine Zahl, oder eine Variable) an das Array an und gibst dieses Zurück. Im Hauptprogramm kannst du das Array dann auslesen und z. B. über jedes Arrayelement (was ja einer Instanz der Artikel-Klasse entspricht) iterieren...
Ich hatte mal folgendes versucht(in der Warenkorb-Klasse):
// einfach den Warenkorb-Array aus der Session ausgeben
function artikel(){
return $_SESSION["warenkorb"];
}
$artikels = $wb -> artikel;
echo "Artikel1: ".var_dump($artikels);Da kommt aber nx an : NULL!
ist die Funktion artikel denn in der Klasse definiert (sorry, dumme Frage)? (im Beispiel ist ja kein class drumm herum, deshalb die Frage). Also, wenn die Funktion in der Klasse für $wb definiert ist, sollte das meines Erachtens schon funktionieren.
Tja, das kommt wohl durch die so späte Stunde, hätte statt
$artikels = $wb -> artikel;
$artikels = $wb -> artikel();
^^
schreiben müssen! Ist nunmal ne Funktion! Jetzt gehts, ich bekomme den Array des kompletten Warenkorbs, was ja aber nicht sinn der Sache war, aber halt zum testen.Ein erste kleine Version meines Session-Klassen-Warenkorbs kannst Du Dir ja mal hier angucken: http://www.knet-systems.de/test/kl.php, Ist erst eine Klasse, baue das jetzt langsam aber sicher aus, er Quellcode steht drunter, vielleicht hast Du ja einen Kommentar dazu!
Kurze Statusfrage: Hier hast du ja keine Artikelklasse verwendet. Ist das nur ein Test, ob die Basis funktioniert? - Wenn du die Artikelklasse implementieren willst, musst ja für jedes Arrayelement von $_SESSION["warenkorb"] eine eigenständige Instanz der Artikel-Klasse erstellen und das Array aller erstellen Instanzen zurückgeben.
Genau so ist es, Testweise erst mal so. Aber meinst Du ich soll nur einen Array mit den Instanzen erstellen? Dann habe ich also die Instranzen der Artikelklasse als Array, aber ich muß ja noch dei anderen Saten einlesen, d.h. pro Instanz noch 3-4 andere Werte, wie Preis, Beschreibung... wo mache ich das denn dann? Wenn ich das so mache, müßte ich das ja dann für jede Instanz extra in der Artikel-Klasse machen, oder? Eigentlich auch egal, wer legt schon mehr als 3-4 Artikel in seinen Warenkorb... und wenns denn sauberer ist...
Viele Grüße
Andreas-
Halihallo
kurz vor dem erholsamen Schlaf...
ich jetzt kurz dahinter ;-)ich auch, hab aber etwas ausgeschlafen ;)
Eine Instanz ist ja nichts anderes als ein Wert... Diese kann ganz wie gehabt an ein Array gepushed werden... Da wird wohl auch mit PHP funktionieren. Also: Für jeden Artikel erstellst du eine entsprechende Artikel-Klassen-Instanz (z. B. $article = neu Artikel). Den Wert von $article fügst du ganz normal (wie eine Zahl, oder eine Variable) an das Array an und gibst dieses Zurück. Im Hauptprogramm kannst du das Array dann auslesen und z. B. über jedes Arrayelement (was ja einer Instanz der Artikel-Klasse entspricht) iterieren...
ist die Funktion artikel denn in der Klasse definiert (sorry, dumme Frage)? (im Beispiel ist ja kein class drumm herum, deshalb die Frage). Also, wenn die Funktion in der Klasse für $wb definiert ist, sollte das meines Erachtens schon funktionieren.
Tja, das kommt wohl durch die so späte Stunde, hätte statt
$artikels = $wb -> artikel;
$artikels = $wb -> artikel();
^^
schreiben müssen! Ist nunmal ne Funktion! Jetzt gehts, ich bekomme den Array des kompletten Warenkorbs, was ja aber nicht sinn der Sache war, aber halt zum testen.Aha. Dann ist das ja so wie bei JS... OK, auch wieder was gelernt...
Ein erste kleine Version meines Session-Klassen-Warenkorbs kannst Du Dir ja mal hier angucken: http://www.knet-systems.de/test/kl.php, Ist erst eine Klasse, baue das jetzt langsam aber sicher aus, er Quellcode steht drunter, vielleicht hast Du ja einen Kommentar dazu!
werd ich mir nachher anschauen... Anwort vielleicht auch über E-Mail.
Kurze Statusfrage: Hier hast du ja keine Artikelklasse verwendet. Ist das nur ein Test, ob die Basis funktioniert? - Wenn du die Artikelklasse implementieren willst, musst ja für jedes Arrayelement von $_SESSION["warenkorb"] eine eigenständige Instanz der Artikel-Klasse erstellen und das Array aller erstellen Instanzen zurückgeben.
Genau so ist es, Testweise erst mal so. Aber meinst Du ich soll nur einen Array mit den Instanzen erstellen?
^^^
Nur??? - Es wäre einfach sehr "schön" (ach her je, der mit seinen Stilanregungen wieder ;)). Ich meine, wenn es ist doch ganz schön, wenn du auf alle Methoden der Artikelklasse zugreifen kannst, als nur so eine einfache Variable zurückzuerhalten... Folgendes kannst du dann machen:
$array = $wk->getArticles();
foreach ($array as $article) {
echo '<h1>'.$article->getDescription.'</h1>';
echo 'Pricing information: '.$article->getPrice.'<br />';
}und so weiter... Ist doch eigentlich ein ganz schöner Aufbau, nicht? - Du brauchst dich im Hauptprogramm dann gar nicht mehr um die Variablen - Datentypen zu kümmern und kannst dich ganz einfach auf die Methoden verlassen. Wenn du dann später auf mysql umsteigst, brauchst du die Hauptprogramme nicht einmal mehr zu ändern...
Dann habe ich also die Instranzen der Artikelklasse als Array, aber ich muß ja noch dei anderen Saten einlesen, d.h. pro Instanz noch 3-4 andere Werte, wie Preis, Beschreibung... wo mache ich das denn dann?
In der Klasse Warenkorb hast du ja die Methode getArticles (welche ein Array mit Instanzen der Klasse Article zurückgiebt). Dort wird ja zu jedem Artikel eine entsprechende Instanz erstellt mit:
my $article = new Article( $articleID ); # irgendwie soll der Konstruktor ja wissen, zu welchem Artikel du überhaupt eine Instanz anlegen willst.
Der Konstruktor (die Methode new) kann dann alle Daten über die Session oder Datenbank holen und diese als Eigenschaften der Instanz speichern (getPrice greift danach auf diese Eigenschaft zu und gibt deren Wert zurück).
Wenn ich das so mache, müßte ich das ja dann für jede Instanz extra in der Artikel-Klasse machen, oder? Eigentlich auch egal, wer legt schon mehr als 3-4 Artikel in seinen Warenkorb... und wenns denn sauberer ist...
Ich glaube ich weiss, was du meinst: Nein, das würde ich nicht so machen. Wie im Beispiel oben, würde ich dem Konstruktor (das ist ja diejenige Methode, welche die Instanz "erstellt") eine ArtikelID übergeben, welche den gewollten Artikel "referenziert"; oder eben den Index, wo der gewollte Artikel in der $_SESSION["warenkorb"] steht. Aber sicher nicht für jeden Artikel eine eigene Klasse basteln (das wär ja heiter...)
Viele Grüsse
Philipp
-
-
-
-
-
-
-
-
-
-
-