nicht angemeldet
Gaaaanz simpler Warenkorb
N'abend,
ich plane die Realisierung eines _hochgradig_ simplen Warenkorbes. Dazu müßt ich (mit perl) kurzzeitig Userdaten - allerdings keine pesönlichen Daten wie E-Mail-Adressen oder Telefonnummern etc sondern _nur_ Artikelnummern/Bestellmengen usw - serverseitig zwischenspeichern (Cookies scheiden aus ). Sowie der User das letztendliche Bestellformular abschickt (spätestens aber einen Tag später) sind alle seine (ohnehin unpersönlichen) Daten vom Server verschwunden.
Der User soll auch nicht wiedererkannt werden. Stürzt ihm währen er seinen Korb zusammenstellt der Rechner ab muß er halt noch mal von vorne anfangen. Nicht besonders comfortable ich weiß aber so soll es halt sein.
Ich brauch natürlich eine Session-ID für den Fall das mal mehrere User gleichzeitig rumhüsern, klar.
Aber muß ich für so einen _simplen_ Warenkorb tatsächlich einen _so_ hohen Aufwand treiben wie ich im Archiv nachlesen konnte? Also gar womöglich mit Verschlüsselungsalgorithmen aus Time-Stamp, IP-Adresse und was weiß ich noch allem eine möglichst eindeutige ID erzeugen? Reicht da nicht einfach eine Zufallszahl?
So hoffe ich denn auf ein "ja" aus dem Forum und danke schonmal bestens dafür.
Gruß,
Jens
-
Hello,
wieso willst Du bei einem hochgradig simplen Shopsystem die Daten auf dem Server speichern?
Wahrscheinlich gibt es doch noch nicht einmal eine Online-Anmeldung.
Daisychain die Daten mittels eines hidden-Fields durch die Formulare. Nimm nur Post und nur ein einziges Form (mehrere Submit-Buttons sind ja möglich) von einem zum anderen, dann gibts da keine Probleme.Da gabs hier heute schon ein paar Thread in PHP. Warum sollte das mit Perl nicht auch gehen.
(End)kontrolle (Plausibilität) ist allerdigns am Ende des Gesamtvorganges dann nochmal nötig.
Der User kennt soch seine Daten sowieso.
Grüße
Tom
-
Hello,
Hallöchen
wieso willst Du bei einem hochgradig simplen Shopsystem die Daten auf dem Server speichern?
Letztendlich wahrscheinlich aus Unkenntnis der 1000 anderen Möglichkeiten
Wahrscheinlich gibt es doch noch nicht einmal eine Online-Anmeldung.
So ist es.
Daisychain die Daten mittels eines hidden-Fields durch die Formulare. Nimm nur Post und nur ein einziges Form (mehrere Submit-Buttons sind ja möglich) von einem zum anderen, dann gibts da keine Probleme.
Mit "Daisychain" ist wahrscheinlich das Anhängen von Daten an die URL gemeint. Und mit "Post" wären die auch unsichtbar. Das ist ein guter Ansatz, bedeutet aber daß ich mich noch ein bißchen mehr mit Perl beschäftigen muß als es mir lieb ist...Das Anlegen von "temporären" Dateien auf dem Server erscheint mit einfacher als URL-Anhänge aufzudröseln. Ich versuchs trotzdem mal mit dem daisychainen...
Da gabs hier heute schon ein paar Thread in PHP. Warum sollte das mit Perl nicht auch gehen.
PHP ist mir _leider_ _völlig_ fremd; Wäre aber vermutlich für solche Anwendungen zweckmäßiger. Nun ja man kann nicht auf allen Hochzeiten tanzen. Perl muß es auch möglich machen können.
Trotzdem besten Dank,Jens
-
Hello,
Mit "Daisychain" ist wahrscheinlich das Anhängen von Daten an die URL gemeint.
Nein, entschuldig bitte. Daisychain heißt "durchschleifen, weiterreichen". hat also nix mit der URL zu tun. Nur eben, dass das von Form zu Server zu Form zu Server von ... immer weitergereicht wird. Und das geht eben am besten mit einem Affenformular.
Wir haben hier heute schon mindestens zwei Threats zu dem Thema gehabt. Da musst Du einfach mal nach "Tom" oder "Sven Rautenberg" suchen. Schlagworte habe ich vergessen.
Und mit "Post" wären die auch unsichtbar. Das ist ein guter Ansatz, bedeutet aber daß ich mich noch ein bißchen mehr mit Perl beschäftigen muß als es mir lieb ist...Das Anlegen von "temporären" Dateien auf dem Server erscheint mit einfacher als URL-Anhänge aufzudröseln. Ich versuchs trotzdem mal mit dem daisychainen...
Das schöne beim Daisychain ist, dass Du überhaupt keine benutzeridentifikation benötigst, also keine Session, keine Anmeldung...
Da gabs hier heute schon ein paar Thread in PHP. Warum sollte das mit Perl nicht auch gehen.
PHP ist mir _leider_ _völlig_ fremd; Wäre aber vermutlich für solche Anwendungen zweckmäßiger. Nun ja man kann nicht auf allen Hochzeiten tanzen. Perl muß es auch möglich machen können.
Das geht bestimmt auch in Perl
man braucht einen Hash (also array in PHP) oder eine definierte Datenstruktur, die man leicht erweitern kann und die man dann irgendwie für HTML unschädlich codiert. In PHP bietet sich da base64-Codierung an. Diese Daten stöpselst Du dann in ein Hidden-Field, die Du beim nächsten Durchlauf am Scriptanfang wieder dekodierst, eiterverwendest und bevor die Daten wirder zum Client gehen, wieder einpackst in das Hidden-Field.
Du musst nur sicherstellen, dass die Navigation innerhalb des Shops nur mit POST-Buttons stattfindet, damit die Variable auch immer mit übertragen wird. In letzten Script werden die Daten dann nach dem Auspacken geprüft und zusammen mit den Kundendaten gespeichert und nochmal angezeigt zum Drucken und einmal an den Kunden gemailt.
Fertig ists
Grüße
Tom
-
Hello,
Und mit "Post" wären die auch unsichtbar. Das ist ein guter Ansatz, bedeutet aber daß ich mich noch ein bißchen mehr mit Perl beschäftigen muß als es mir lieb ist...Das Anlegen von "temporären" Dateien auf dem Server erscheint mit einfacher als URL-Anhänge aufzudröseln. Ich versuchs trotzdem mal mit dem daisychainen...
Das schöne beim Daisychain ist, dass Du überhaupt keine benutzeridentifikation benötigst, also keine Session, keine Anmeldung...
Das geht bestimmt auch in Perl
Auf jeden Fall geht das auch mit PERL ;-)
hier ein Beispiel:
http://www.linux-magazin.de/Artikel/ausgabe/1998/04/CGI/cgi2.htmlDer einzigste Nachteil gegenüber einer Session ist: Der Warenkorb ist nur in einer Richtung begehbar = Aus einer vorgefertigten Liste die Anzahl der gewünschten Artikel auswählen und weiter klicken. Dabei werden die Artikel + anzahl in hidden Fields (oder in der URI) gespeichert. Backbutton ist möglich (zur Korrektur). Wenn der User meint, die Liste ist ok, klickt er auf Bestellen -> die Mail an den Anbieter geht raus und er sieht seine Bestellung die er ausdrucken kann.
Noch einfacher: Das Formular zeigt eine Liste mit den Artikeln und die Eingabefelder für Customer. Beim Abschicken geht die Bestellung gleich raus http://www.raschauski.de/Basis3frame.html.
In einer Richtung begehbar: Der Customer kann nicht aus verschiedenen Listen die Artikel auswählen, das geht nur mit einer Session.
Erwin
--
SELFforum - Das Tor zur Welt!
Theoretiker: Wie kommt das Kupfer in die Leitung?
Praktiker: Wie kommt der Strom in die Leitung?-
Hello,
Der einzigste Nachteil gegenüber einer Session ist: Der Warenkorb ist nur in einer Richtung begehbar =
In einer Richtung begehbar: Der Customer kann nicht aus verschiedenen Listen die Artikel auswählen, das geht nur mit einer Session.
Da hast Du meine Programme in PHP aber noch nicht gesehen!
Solange man sich den User konsequent mit POST durch die verschiedenen Shops bewegen kässt, ist alles möglich. Ich brauche auch nur EIN EINZIGES Hidden-Field.
Szenario:
Portal mit vielen Seiten von _verschiedenen_ Anbietern. Virtueller Einkaufsbummel ist möglich. Der User kann von Shop-Seite zu Shop-Seite mit POST wechseln. Überall kann er Waren einsammeln aus den diversen sogar unterschiedlich formatierten Listen. Er kann sogar auch euf eine Übersichtsseite schalten und einzelne Waren wieder löschen.Am Ende übergibt er diese Liste dem Kontroll-, Berechnungs-, Bestellmodul und die Sache ist perfekt.
Die Nachteile sind eben:
- kein authentifizierter User. Es muss jedes Mal auf's neue
die gesamte Belehrungsarie durchgehampelt werden und man
muss bangen, ob der überhaupt existiert. - erhöhtes Datenaufkommen. Ist allerdings angesichts der fetten
Bilder, die die meisten sowieso von Ihren Produkten und Läden
haben wollen, zu vernachlässigen. Die 5-10kb Bestelldaten
machen da nix mehr aus. - Bei Schließen der Seite oder Verlassen mit Link sind die
Daten futsch - KEIN Online-Booking möglich. Online-Booking: Im Moment der
Artikelbuchung wird dieser für den Kunden reserviert. Das
ist besonders im Chargen-Geschäft B2B wichtig. Wenn man dann
die Option zurückgibt oder nicht innerhalb einer bestimmten
Zeitspanne bestätigt, kostet das auch.
Vorteile:
- Serverlast sehr niedrig (Sessions kosten)
- Kunde muss keine Angst haben, dass er "registriert" wird
- Schließen des Shop-Fensters führt zur Löschung der
gesammelten Daten.
Grüße
Tom
- kein authentifizierter User. Es muss jedes Mal auf's neue
-
-
-
-