Ist das so elegant gelöst`oder gibt es bessere Möglichkeiten

[murat1895]

Hallo Zusammen!

Ich wollte mal eure Meinung zu folgendem Thema hören.

Ich habe einen Onlineshop gebaut. Der Warenkorb wird in einer PHP-Session abgelegt.
Um die Artikel in den Warenkorb zu bekommen, ist bei dem Hinzufüge-Button für den Warenkorb eine JavaScript-Funktion hinterlegt. Dieser JS-Funktion werden bei Klick Parameterübergeben (Artikelnummer). Die Javascript-Funktion schaut dann zunächst, welche Anzahl und welche Variante des Artikels ausgewählt wurden und speichert diese in Variablen.

Nachdem wird die aktuelle URL genommen (da ich die derzeitige Artikelkategorie etc nicht verlieren will), und die Artikelnummer, Anzahl und Variante (falls vorhanden) angehangen (http://192.168.182.151/?gruppe1=00&add=ML0001&anz=1). Somit wird die ganze Seite im Prinzip neu geladen. Im nächsten Schritt überprüfe ich, welche Parameter in der URL gesetzt sind. Sind die entsprechenden Parameter für das hinzufügen in den Warenkorb gesetzt, wird dieser dem aktuellen Warenkorb beigefügt.

Allerdings finde ich das übergeben der Parameter via URL eher unschön, da der Benutzer dieses sieht.

 

[JimTheLion]

Nutz Ajax.

Sammel dir per JavaScript die Daten die du für den Warekorb brauchst und sende sie per Ajax als Post-Request an einen verarbeitenden Endpunkt im Backend.

In der Verarbeitung werden die gesendeten Daten validiert und wenn bei korrekten Daten in die Session geschrieben. Dann lässt du noch eine Meldung zurückgeben ob die Daten dem Warenkorb hinzugefügt wurden oder nicht, ob die Daten vielleicht invalide waren etc.

Im Frontend nimmt dein JavaScript die Antwort vom Backend entgegen und du kannst entsprechend Feedback an den User geben z.B. "Zum Warenkorb hinzugefügt", Anzahl der Produkte im Warenkorb aktualisieren, "Fehler ist aufgetreten"....

 

Das ganze passiert dann ohne refresh der gesamten Seite und in der URL erkennt der User auch nicht was da passiert ist.

Den Warenkorb kannst du natürlich über Sessions umsetzen, aber warum nicht über eine Datenbank?

[Crash2001]

Es gibt erst einmal grundlegend 4 Arten, um Daten zu übergeben bei PHP.

• die Übergabe mittels URL, genannt $_GET
• die Übergabe aus einem (HTML)-Formular heraus, genannt $_POST
• die Speicherung der Daten in einer Session, $_SESSION
• die Speicherung von Daten in einem Cookie, $_COOKIE

die GET-Variante sollte man, wenn möglich komplett vermeiden, oder aber nur für die Navigation auf der Seite nutzen denn sie bietet die Möglichkeit, die URL ganz einfach anzupassen.

Per POST-Methode verändert sich die URL nicht und es ist nicht mehr ganz so einfach zu editieren - ist also schon mal besser.

Empfehlen würde ich jedoch eher die Session- oder Cookie-Variante, da sie nicht ganz so einfach manipuliert werden können und einiges vielseitiger sind.

So kannst du z.B. per GET-Übergabe die aktuelle Seite mitgeben und im Cookie oder in der Session dann alle anderen Daten hinterlegen.

Wenn du den Warenkorb eh schon per Session füllst, dann verstehe ich nicht, wieso du dann zusätzlich noch einmal per GET die selben Daten quasi noch einmal übergeben willst. Du kannst doch die Daten direkt aus der Session übernehmen.

[arlegermi]

Es kommt ganz drauf an, wie komplex das werden darf. Am schönsten ist es, wenn die Seite gar nicht neu geladen werden muss, um Artikel in den Warenkorb aufzunehmen. Das würde für eine reine JS-Lösung sprechen. Wenn der Warenkorb eines Kunden auf allen Geräten identisch sein soll, dann kommst du nicht drum herum, diesen in einer Datenbank zu speichern (bspw. über asnychrone JS-Aufrufe einer API).

Von der Übergabe der Artikel mittels URL würde ich komplett absehen, das irritiert nur und kann beim Verlinken von Seiten zu Missverständnissen führen (wenn nur durch Besuchen der Seite direkt der Warenkorb gefüllt wird).

Um Manipulation würde ich mir allerdings an der Stelle eher weniger Sorgen machen. Alles, was vom Client kommt muss auf dem Server sowieso überprüft werden. Ob sich da jetzt jemand Artikel in den Warenkorb legt, die ausverkauft sind oder Artikelnummern angibt, die es gar nicht gibt - das muss später sowieso auffallen.

[murat1895]

Ich melde mich nochmal kurz zu Wort.

vor 34 Minuten schrieb arlegermi:

...Wenn der Warenkorb eines Kunden auf allen Geräten identisch sein soll, dann kommst du nicht drum herum, diesen in einer Datenbank zu speichern (bspw. über asnychrone JS-Aufrufe einer API)....

Der Kunde verwendet ausschließlich ein Gerät zum Befüllen des Warenkorbs. Daher würde ich ungerne die Daten schon beim hinzufügen in die Datenbank ablegen. Nachdem die Bestellung abgeben wurde, wird dieses logischer Weise aber in der DB festgehalten. Der Kunde hat nun die Möglichkeit, bei einer erneuten Bestellung den entsprechenden Warenkorb einer noch offenen Bestellung zuzuordnen. Eine Bestellung ist offen, wenn diese noch nicht "angefasst" wurde.

Daher muss ich ja schon mit Cookies oder einer PHP-Session arbeiten.

Ich glaube ich kann dann doch besser mit Cookies arbeiten oder? Da ich dann nicht die ganze Seite neu aufrufen muss sondern entsprechenden JS-Code aufrufen kann?

[murat1895]

vor 2 Stunden schrieb Crash2001:

Wenn du den Warenkorb eh schon per Session füllst, dann verstehe ich nicht, wieso du dann zusätzlich noch einmal per GET die selben Daten quasi noch einmal übergeben willst. Du kannst doch die Daten direkt aus der Session übernehmen.

Ich müsste eine PHP-Funktion bei dem onclick-Ereignis aufrufen. Bei einem Onclick-Ereignis kann ich ja nur eine JS-Funktion aufrufen.

[sas86ks]

vor 27 Minuten schrieb murat1895:

Ich müsste eine PHP-Funktion bei dem onclick-Ereignis aufrufen. Bei einem Onclick-Ereignis kann ich ja nur eine JS-Funktion aufrufen.

Genau für so etwas gibt es Ajax.

 

Schreibst du allen Ernstes ein Shopsystem selber? Entschuldige die provokative Frage aber da gibt es 1000 Fallstricke. Benutz doch lieber ein fertiges System.

[murat1895]

Klar, sonst lernt man´s ja nie! Ich weiß das es genügend Shop-Systeme gibt. Allerdings nicht so, wie ich es brauche. Das ganze hier ist eine ziemlich komplexe Struktur, deshalb kann ich nicht einfach ein fertiges Shopsystem nehmen und alles läuft. Ich denke, da würde dann ne Menge Zeit für Anpassungen etc. draufgehen, da das Shopsystem an unser ERP-System angebunden wird. Die Anbindung zum ERP-System steht auch schon ganz, dort befinden sich logischer Weise auch die Artikel, die im Shop angezeigt werden mit Verfügbarkeit und und und ... . Die Benutzer werden via LDAP-Authentifiziert. Ich brauche also keinen vollwertigen Onlineshop, in dem ich Artikel erstelle, Benutzer verwalte oder Kategorien erstelle. Im groben und ganzen steht auch schon alles.

[sas86ks]

Wird der Shop öffentlich erreichbar sein? Ich hoffe ihr habt einen guten Anwalt, denn ich sehe da eine große Abmahnungsgefahr.

Shopsysteme (z.B. Magento) sind wunderbar modular aufgebaut, d.h. du kannst sie super einfach mit Plugins usw. erweitern und an deine Bedürfnisse anpassen.

Gerade wenn dir so Grundlagen wie Ajax fehlen, würde ich mir das alles noch mal reichlich überlegen. Spricht natürlich nichts dagegen für dich intern ein Shopsystem zu programmieren um daran zu lernen.

Bearbeitet 17. März 2016 von sas86ks

[murat1895]

Nein, das Shopsystem ist lediglich für die Mitarbeiter der Firma gedacht und auch nur im Firmennetz erreichbar.

Dennoch würde mich interessieren wo die Abmahnungsgefahr liegt?

[sas86ks]

Ok bei einem internen Projekt sollte das nicht gegeben sein.

Bei öffentlichen Shops gibts eine ganze Reihe von Regeln, die man beachten muss um nicht abgemahnt zu werden (z.B.: http://www.pc-magazin.de/ratgeber/abmahnung-ade-online-shop-rechtssicher-inkl-fibel-download-192333.html).

Bei sowas würde ich immer einen Anwalt, der sich damit auskennt, drüber gucken lassen.

Bearbeitet 17. März 2016 von sas86ks

[pr0gg3r]

Erst einmal solltest du den Onlineshop so programmieren, dass er komplett ohne JavaScript funktioniert. Das heißt, die Daten (zB beim Hinzufügen in den Warenkorb) über Post oder Get an ein PHP-Script übergeben (und ggf. zur Seite oder zum Warenkorb umleiten). In PHP hast du eine Session, mit der du den Benutzer identifizieren kannst. Die Daten der Bestellungen kannst du serverseitig entweder auch in der Session, in Textdateien oder am besten in einer Datenbank speichern (zB zwei Tabellen, eine für die Session und eine für die Artikel im Warenkorb). Die Session ist dem Client (Browser) so lange zugeordnet, wie er geöffnet ist (bzw. wies serverseitig konfiguriert wurde). Wenn du jetzt möchtest, dass der Benutzer auch bei einem erneuten Browserstart identifiziert wird, kannst du auch mit Cookies, also JavaScript, arbeiten. Am besten dann noch einen Cronjob laufen lassen, der alle alte Sessions und Warenkörbe löscht.

Erst wenn es serverseitig funktioniert, solltest du den Shop mit JavaScript erweitern, also zB die Artikel per JavaScript und Ajax-Request dem Warenkorb hinzufügen. Da du die Funktionalität serverseitig dann bereits hast, ist die Erweiterung ein Kinderspiel.

[Colamann]

vor 8 Stunden schrieb Crash2001:

Es gibt erst einmal grundlegend 4 Arten, um Daten zu übergeben bei PHP.

[...]

• die Speicherung der Daten in einer Session, $_SESSION

Diese Verwendungs von Sessions wäre mir neu... Kannst du das bitte kurz erläutern?

Bearbeitet 17. März 2016 von Colamann

[Crash2001]

Ist ganz einfach und vor allem können die Variablen über mehrere Seiten hinweg in der Session gespeichert werden.

 

<?php

//Session starten
session_start();

//Variable befüllen
$_SESSION['name'] = "wert";

//Variable ausgeben
$name = $_SESSION['name'];
echo $name;

?>

Howto zu Sessions

Session Basics von PHP.net

[JimTheLion]

Aber an der Stelle bist du schon im verarbeitenden Teil, die Übergabe aus dem Request ist an der Stelle schon erfolgt. Deshalb passen die Punkte "Speicherung in Session", "Speicherung in Cookie" nicht in die Auflistung der Arten zur Übergabe von Werten (edit: wenn es um die Übergabe vom Client an den Server geht).

Bearbeitet 18. März 2016 von PVoss

[Crash2001]

Man muss die Daten natürlich per Formular übergeben bzw. es muss per AJAX entsprechend gefüllt werden.

[ne0e]

Am 17.3.2016 um 14:31 schrieb murat1895:

Klar, sonst lernt man´s ja nie! Ich weiß das es genügend Shop-Systeme gibt. Allerdings nicht so, wie ich es brauche. Das ganze hier ist eine ziemlich komplexe Struktur, deshalb kann ich nicht einfach ein fertiges Shopsystem nehmen und alles läuft. Ich denke, da würde dann ne Menge Zeit für Anpassungen etc. draufgehen, da das Shopsystem an unser ERP-System angebunden wird. Die Anbindung zum ERP-System steht auch schon ganz, dort befinden sich logischer Weise auch die Artikel, die im Shop angezeigt werden mit Verfügbarkeit und und und ... . Die Benutzer werden via LDAP-Authentifiziert. Ich brauche also keinen vollwertigen Onlineshop, in dem ich Artikel erstelle, Benutzer verwalte oder Kategorien erstelle. Im groben und ganzen steht auch schon alles.

Kleiner Vorschlag:

Durch die Authentifizierung über LDAP würde ich den Warenkorb in der Datenbank speichern und dem Benutzer vielleicht sogar die Möglichkeit geben mehrere Warenkörbe anzulegen.

Da der Shop nur intern genutzt wird weist du sicher auch ob die Browser Javascript aktiviert haben oder nicht und kannst dich ganz auf eine Methode konzentrieren.
AJAX ist auf jeden Fall anzuraten da nicht bei jedem Event die Seite neu geladen werden muss.

Bitte beachte das auch bei rein firmeninterner Verwendung einige rechtliche Aspekte wichtig sind, allein die Widerrufsbelehrung und die AGB's. Zwar hat kein Außenstehender Zugriff und kann dementsprechend auch keine Abmahnung veranlassen, doch je nach Größe und Struktur der Firma können damit einige Streitigkeiten vermieden werden.

 

[Ulfmann]

Am 3/17/2016 um 16:25 schrieb pr0gg3r:

Erst einmal solltest du den Onlineshop so programmieren, dass er komplett ohne JavaScript funktioniert.

Gibt es im Jahr 2016 wirklich noch Menschen, die ohne unterwegs sind?! 

[pr0gg3r]

vor 25 Minuten schrieb Ulfmann:

Gibt es im Jahr 2016 wirklich noch Menschen, die ohne unterwegs sind?! 

Es geht viel eher darum, dass dem TE erhebliche Grundlagen der Funktionsweise fehlen. Wenn der Shop erst ohne JS funktioniert, ist es ein Leichtes, die Funktionalität mit Ajax nachzurüsten. Ob man die Daten dann per Link (GET) oder Formular (GET, POST) oder per Ajax (GET, POST) an PHP weitergit, ist wurst, erst einmal muss das aber serverseitig (PHP) funktionieren, ohne das kann er so viel mit JS und Ajax rumwursteln wie er möchte, wird dann aber nicht weit kommen. Natürlich kann man das auch direkt mit JS und Ajax umsetzen, aber er muss das Denken erst Enwtickeln, wie per HTTP generell Daten übermittelt und Empfangen und anschließend auf dem Server weiterverarbeitet werden.

Natürlich kann man eine Zielgruppenanalyse und derren technischen Gegebenheiten der Umsetzung vorziehen

[Ulfmann]

Natürlich, so gesehen hast du völlig Recht. Ich dachte dein Argument war, sicherzustellen, dass auch wirklich jeder Neandertaler dieses Tools benutzen kann.

[DashDash]

Ich finde den Fokus den "Refresh" der Seite verhindern zu wollen falsch. "Kein Refresh" zu haben ist ein UX Detail, das später gerne nachgerüstet werden kann. HTTP ist ein zwar schon etwas älteres Protokoll aber es hat das Internet ermöglicht zu entstehen und auf aktuelle Größe zu skalieren - also keine falsche Scheu das auch so zu nutzen. Generell erstmal folgendes, mit einem HTTP GET forderst du eine Ressource (z.B. die Seite) an, dabei wird nichts an den Daten verändert - d.h. es wird nicht z.B. für updates oder erstellen genutzt. Um z.B. einen neuen Eintrag in den Warenkorb zu tätigen würdest du eher einen HTTP POST nutzen. Bei einem HTTP POST werden die Daten im Body des HTTP Requests übertragen und nicht in der URL. Damit würde ich anfangen, wenn der Server deinen POST request bearbeitet hat (und den Inhalt aus dem Request in z.B. eine Datenbank oder die Session getan hat) dann kannst du z.B. redirecten oder eine Warenkorb Übersichtsseite anzeigen.

Das so zu machen hat auch wichtige Bedeutung für die Sicherheit deiner Seite. Operationen wie create oder update sollten niemals per GET übertragen werden, weil du dann allerlei Probleme mit Sachen wie CSRF (Cross Site Request Forgery) bekommst.