Hallo zusammen,
seit kurzem befasse ich mich mit PHP und mich würde interessieren, wie ihr beim folgenden, bestimmt häufigen Fall vorgehen würdet:

Ich benutze eine mySQL Datenbank und möchte mittels eines Formulars Datensätze ändern, hinzufügen können.
Ich habe nun eine Seite erstellt, die die Informationen erhält ob geändert oder hinzugefügt werden soll, und welche Tabelle bzw. bei Änderungen welcher Index geändert wird (fortan: Datenbank-Daten).
Im Formular sollen nun Daten eingegeben werden können, die dann in der Tabelle gespeichert werden. Diese möchte ich, falls meine Fehlerprüfung einen Fehler feststellt, erneut im Formular anzeigen und farbig markieren. (fortan: Formular-Daten)

Nun will ich beim Bestätigen der Daten also sowohl die Formulardaten (die ich also gerade "frisch" eingegeben habe) als auch die Datenbankdaten (welche mir bereits übergeben wurden) übergeben.

Mein "Problem" ist nun, wie die Daten am sinnvollsten übergeben werden sollen.

Bislang habe ich mir das so vorgestellt:
Die Formularseite macht wird sowohl für Hinzufügen/Ändern als auch für die Anzeige der fehlerhaften Einträge nach dem Bestätigen des Hinzufügengen/Änderns genutzt.
Es wird erkannt, ob die Seite über GET oder POST aufgerufen wurde:
- Beim Aufruf zum Hinzufügen/Ändern übergebe ich die Datenbankdaten per GET und schreibe sie sofort in eine SESSION-Variable. (GET, da ich die Seite momentan einfach per Link aufrufe, da ich kein Formular benötige um die Seite aufzurufen)
- Das Formulardaten übergebe ich dann per POST an die selbe Seite und hole mir die Datenbank-Daten aus der Session-Variablen.

Ist das komplizierter gemacht/gedacht als es ist, oder welche Vorschläge habt ihr hierzu.

Danke für eure Hilfe

Oha - da fehlt es wirklich noch ein wenig an Erfahrung ...

Es gibt da ein paar grundsätzliche Überlegungen wie man einen Datenbankeditor
aufbaut.

1. Datensatz ändern: Der zu ändernde Record muß erst einmal selektiert und
angezeigt werden. Dann braucht es noch irgendetwas, damit die Datenbank
später beim Speichern auch den richtigen Record ändert (zB Recordnummer
oder einen physical key).

2. Datensatz neu: Es besteht das Risiko, daß einer doppelt abgelegt wird (zB
Doppelclick oder keine Änderung). Vielleicht mit einem leeren Record anfangen ?

3. Datensatz löschen: Potentiell gefährlich.

1-3 wird über das CGI-Programm abgesichert. uA auch gegen SQL-Injections.

Die Vorprüfung der eingebenen Daten sollte im Client erfolgen (zB Feld leer).

Nebenbei haben Datenbankdaten nichts in einer "SESSION"-Variablen verloren
(was soll das denn eigentlich ein ?). Du solltest erst einmal den User der ändert,
identifizieren (uA Zugriffsrechte) und dann das in einem Cookie speichern damit
das CGI beim Speichern weiß, daß nicht irgendein Häcker aus Honkong das
abgesendet hat.

Ich empfehle Dir, das stückweise aufzubauen, Online zu stellen und hier weiter
zu debattieren. Hau rein.

Grüße Joe.

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Hallo Joe,

danke für deine Antwort.

Fehlende Erfahrung, oh ja , wobei die sich mehr auf die Webentwicklung als auf Datenbanken bezieht.

Daher sehe ich grundsätzlich die ersten 3 Punkte als schon ziemlich erfüllt bei mir an. (Datensätze sind eindeutig, lassen sich selektieren, und ich kann die Ergebnisse anzeigen, in Formularen ausgeben, etc.) Der Hinweis auf die Gefahren eines Doppelklicks war aber ein guter Tipp.

Als "Probeanwendung" bastel ich gerade an der Verwaltung einer Adressdatenbank, da diese nur ich benutze habe ich bislang auch noch keine Useridentifikation eingebaut.

Meine Frage bezieht sich jedoch vielmehr auf die Übergabe von Daten.
Ein einfaches Beispiel:
Auf einer Seite werden sämtliche Informationen einer Person aus verschiedenen Tabellen angezeigt. Z.B. seine Privat- und Geschäftsadresse (beide aus der Tabelle "Adressen"), seine Handy- und Festnetznummer (beide aus der Tabelle "Telefon"), etc.
Ich möchte nun beispielsweise die Handynummer ändern und klicke auf diese (Link). Nun müssen im aufgerufenen File folgende Informationen vorhanden sein:
- Eindeutiger Index des zu ändernden Datensatzes
- Tabelle, in welcher sich der Datensatz befindet
- evtl. sogar so etwas wie die Aktion die ich ausführen möchte (Ändern, Anlegen)
Dies ist über GET ja problemlos möglich. (In einer Session speichern ist ja nicht möglich, da ich erst beim anklicken weiss, welcher Datensatz selektiert werden soll - und ein POST ist ja auch nicht wirklich geeignet).
Im nun aufgerufen File bereite ich ein Formular auf, indem ich die Daten ändern kann. (Bis hierhin ist alles problemlos)
Um die Daten abzuschicken kann ich POST benutzen, wobei ich dann auf der zur Datenverarbeitung (Fehleranalyse, Datenbankkommunikation, etc.) benutzen Seite zwar dann die Feldinhalte des Formulars über POST erhalte, mir jedoch die vorher über GET übergebenen Variablen nicht mehr zur Verfügung stehen, da ich ja nur die Inhalte innerhalb eines Forms übergeben kann. Daher kam mir die Idee, die aktuelle Tabelle, den aktuellen Index in einer Session zu speichern - einfach um so etwas wie eine übergreifende ("globale") Variable zur Verfügung zu haben.

Ist das üblich, oder was wäre der "übliche" Weg zur Übergabe mehrer Variablen?

Im Grunde hat Joe schon alles gesagt, aber ich versuche es trotzdem auch nochmal, auch wenn einiges doppelt sein wird.

Zunächst einmal solltest Du den Datensätzen (Zeilen in Deiner Datenbank-Tabelle) einen Primärschlüssel (Primary key) geben, falls noch nicht geschehen. Die Zeile, die Du ändern möchtest kannst Du dann bequem über den Primärschlüssel abfragen.

1. Anzeige des Formulars
   Du selektierst den Datensatz mit der übergebenen ID, falls keine ID übergeben wurde, dann nicht. Die Daten kannst Du dann ins Formular übernehmen. Dafür brauchst Du keine Session.
2. Abschicken des Formulars
   Entweder Du siehst ein hidden-Field vor, welches die ID (Primärschlüssel) des zu ändernden Datensatzes enthält, oder Du übergibst die ID per GET (Man kann GET und POST mischen). Dann kannst Du einfach wieder den Datensatz aus der Tabelle lesen, der der ID entspricht und auf Änderungen prüfen, dafür brauchst Du keine Session.

Wie beschrieben brauchst Du keine Session, um die Daten zu bearbeiten. Das Speichern in der Session würde das nur unnötig kompliziert machen, denke ich. Alles was Du brauchst sind die Daten, die geändert werden sollen und die ID des Datensatzes, der geändert werden soll. Falls keine ID angegeben ist, dann wird ein neuer Datensatz angelegt.

Trotzdem solltest Du Joe's Hinweis bzgl. der Sicherheit beachten, die betreffenden Seiten also mit einem Login absichern (hier kommt dann tatsächlich die Session ins Spiel) und den Code SQL-Injection-save schreiben, also immer schön escapen.

Ups, jetzt hab' ich wohl zu lange gebraucht und Du hast schon auf Joe geantwortet.

Zu Deiner Frage, siehe oben: Man kann GET und POST mischen, so mache ich das immer. Die ID wird bei mir immer über GET geliefert, wohingegen die Daten über POST kommen. Es spricht ja nichts dageben z.B. "edit?id=3" als action im Formular anzugegen.

Ok, wunderbar, danke für die Antwort.

Wie gesagt, das Zugreifen über Primärschlüssel auf Datensätze etc ist mir klar.

Es ging mir nur um das von dir erwähnte "Mischen" von POST und GET.
Dann ist ja klar wie ich weiter vorgehe.

Ich wusste nur nich, ob es da eine empfohlene Methode unter euch Erfahrenen gibt, und ob ein "edit?id=3" im POST nun eher "Standard" und geschickt, oder "unsauber" und getrickst (z.B. im Vergleich zu hidden fields)ist Aber wenn mischen kein Problem ist, sollten sämtliche Probleme ja gelöst sein.

Ich versteh nur noch nicht genau, warum ihr mir vom Speichern von Variablen in einer Session abratet, so komplex sieht das doch garnicht aus

Und was haltet ihr davon, immer wieder kehrende, häufige Variablen in einem externen File zu speichern und mittels include immer wieder einzufügen (ich denke hier an Feldnamen von Tabellen in einem Array, deren Langtext (= Anzeigetext) etc.)

Alles geht ...

HTTP-Server wie zB Apache kennen keine Session-ID, eigentlich braucht man die
auch nicht wenn man weiß wer gerade eingeloggt ist. Also einfach die Logindaten
irgendwie in einem Cookie verstecken und bei jedem CGI-Aufruf ein komplettes
Login, natürlich mit einem timestamp (zB time()) absichern (damit sich keiner aus
der Adresszeile Sachen rauskopiert und recycled).

Variable werden nicht "includet", da geht es um Dateien (wie die aussehen
und was darinnen ist bestimmst Du nebenbei auch selbst).

Benutzerabhängige Variable kannst Du dann in einer Datei unter dem Usernamen
intern speichern, die gehen dann nicht nach außen.

"Sauber" ist einen Lösung dann wenn sie funktioniert und Du weißt warum

Grüße Joe.

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Da muss ich widersprechen. Logindaten sollten niemals in einem Cookie gespeichert werden, lediglich die Session-ID ist in einem Cookie zu speichern. Und auch hier sollte ein "gesunder" Timeout gewählt werden, damit die Session nicht dauerhaft eingeloggt bleibt.

Ob das mischen von GET und POST nun "sauber" und profihaft ist kann ich nicht sagen. Ich selbst habe dies früher immer über hidden-Fields gemacht, bis ich mich mal gefragt habe: "Warum der Blödsinn?".

Ich sehe das so:
Der Request lautet umgangssprachlich "Bearbeite den Datensatz mit der ID X", also sollte die URL auch ".../edit?id=X" lauten, oder halt per mod_rewrite "../edit/X". Ich unterscheide dann anhand der Request-Typs, ob es sich um die Anzeige des Formulares handelt, oder um das abgeschickte Formular. Also wenn PHP sagt, dass es ein POST-Request ist, dann werden Daten geliefert und der Datensatz soll geändert/erzeugt werden, wenn es ein (reiner) GET-Request ist, dann soll der bzw. ein leerer Datensatz angezeigt werden.

Allerdings leite ich POST-Request nach der Verarbeitung mittlerweile auch direkt (ohne jegliche Anzeige, also per 302-Redirect) auf den entsprechenden GET-Request um, der dann den gespeicherten Datensatz anzeigt. Dazu gibt es auch ein Pattern, das afaik POST-Redirect-GET heisst, was im Grunde nur aussagt, dass nur GET-Requests eine Anzeige von Daten zur Folge haben. POST-Requests hingegen sollen Daten annehmen, verarbeiten und anschließend per GET weiterleiten.

In eine Datei würde ich jetzt nicht unbedingt extra was speichern, dann kann man ebensogut die Session nehmen, wenn sie (zwecks Login zum Beispiel) eh schon da ist. Aber es hält Dich niemand davon ab Daten in der Session zu speichern, wenn Du meinst, dass es sinnvoll ist. In dem beschriebenen Fall halte ich das aber eben nicht für sinnvoll.

Kommt drauf an. Wenn das Cookie ein Verfallsdatum hat geht es. Es muß ja
nicht unbedingt Standard sein ... Ich bilde die Session ID aus Usernamen, einem
time() und anderem Kleinkram. Nicht mit USER=ICH

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator

Ich habe das zitierte so verstanden, als ob Du dazu raten würdest die Login-Daten (Username/Password) ins Cookie zu speichern, da Du auch schriebst "...bei jedem CGI-Aufruf ein komplettes Login". Wenn Du eine Session-ID generierst (wie auch immer die aussieht, aber bitte ohne Password ), dann habe ich nichts gesagt.

Natürlich nicht im Klartext. Es ginge auch, nur den MD5 zu speichern ...

__________________
Grüße aus dem Spessart, Joe

{ table-layout: biertischistbesser; }
Der Mausinator