Userführung und Mehrfachaktion

WiZdooM

Erfahrenes Mitglied
Hey Leute,

das Problem, welches ich hier habe betrifft PHP, JS und HTML.

Das Formular wird geladen, der Benutzer füllt es aus, schickt es ab. Ist alles valide, bekommt der Benutzer eine Übersicht mit den Optionen zurück und Drucken.
Klickt der Benutzer auf Drucken soll folgendes passieren:
1.) Eine Nummer wird aus der Datenbank gelesen und in die Übersicht eingefügt damit
2.) ein Javascript diese Übersicht nun ausdrucken kann und
3.) ein PHP-skript schreibt die Daten aus den Formularfeldern in die DB.
4.) Ist das geglückt, soll der Benutzer eine Danke-Seite angezeigt bekommen

Bisher läuft es so ab: Nach der Validierung bekommt der Benutzer seine Übersicht. Klickt er auf Drucken, bekommt er seinen Druck (jedoch ohne die Nummer), den Eintrag in die Datenbank sowie seine Danke-Seite.

Ich weiß jetzt einfach nicht wie ich unmittelbar vor dem Druck die Nummer in mein Formular einfügen kann. Warum nicht beim Aufruf der Seite die Nummer einfügen? Ganz einfach: Ist der Benutzer über längere Zeit in der Übersicht ohne die Daten zum Eintrag in die Datenbank zu bestätigen, besteht die Möglichkeit, dass ein anderer Benutzer die Nummer, die auch der erste Benutzer angezeigt bekommt, in der Übersicht stehen hat.
Während nun in der Übersicht und in der Datenbank von Benutzer zwei die Nummern identisch sind, sind die Nummern von Benutzer eins in der Übersicht und in der Datenbank verschieden.

Ich habe mir nun folgendes gedacht: Der Benutzer klickt auf Drucken, das Formular schickt sich an sich selbst und erlaubt sich selbst die Nummer einzutragen, wenn das geschehen ist greift das JS und öffnet den Druckdialog. Nun erfolgt eine Weiterleitung auf das Skript dass die Daten in die DB schreibt und im Erfolg die Danke-Seite anzeigt.
Hier weiß ich jedoch nicht wie ich das alles so realisieren soll :/

Eine andere Möglichkeit wäre ein neues Fenster zwecks Druck zu öffnen, und im Originalfenster erfolgt der Eintrag in die DB und die Anzeige der Danke-Seite.

Stehe hier echt mal auf dem Schlauch - vielleicht denke ich auch zu kompliziert und es ist ganz einfach zu realisieren.
 
Hi,

Das Formular wird geladen, der Benutzer füllt es aus, schickt es ab. Ist alles valide, bekommt der Benutzer eine Übersicht mit den Optionen zurück und Drucken.

Warum werden die Daten an dieser Stelle noch nicht in die Datenbank geschrieben, wie man es erwarten würde? Dann wäre der Datensatz angelegt und die Nummer (wo auch immer die herkommt) vergeben, und Du kannst sie auf der Folgeseite anzeigen.

Klickt der Benutzer auf Drucken soll folgendes passieren:
1.) Eine Nummer wird aus der Datenbank gelesen und in die Übersicht eingefügt damit
2.) ein Javascript diese Übersicht nun ausdrucken kann und
3.) ein PHP-skript schreibt die Daten aus den Formularfeldern in die DB.
4.) Ist das geglückt, soll der Benutzer eine Danke-Seite angezeigt bekommen

Warum ist das Schreiben in die Datenbank an die Druckfunktion gekoppelt? Das halte ich für sehr unklug und für den Benutzer auch sehr undurchsichtig. Was ist, wenn das Eintragen in die DB schiefläuft? Dann hat der Benutzer einen Ausdruck der Daten, die in der DB nie angekommen sind.
Was ist, wenn er gar keinen Ausdruck will? Er wird davon ausgehen, dass die Daten trotzdem gespeichert sind, er hat sie ja abgeschickt.

Sind das wieder die Vorstellungen von Deinem Chef?

LG
 
Hi

Wo soll ich anfangen ... is irre kompliziert.
Wir haben hier eine Access Datenbank in der Händler, Kunden, Fahrzeuge, Außendienstmitarbeiter, Schadensdaten usw drin gespeichert werden.
Bisher ist es so, dass der Händler bei sich ein Papierheftchen hat. In diesem Papierheftchen ist ein Formular wie das was ich online umsetzen muss.
Dieses Formular füllt der Händler mit dem Kunden aus, wenn dieser das Möchte und schickt das dann an uns das original per Post und gibt dem Kunden einen Durchschlag.Wenn der Brief hier mit dem Formular ankommt, wird das per Hand in die Access DB gehackt.
Um nun von dem Papierkram wegzukommen, soll ich nun das Formular online verfügbar machen.
Dort tragen dann die Händler mit den Kunden (oder auch schon vorher) die Daten ein. Wenn er den Aufrag an uns abschließt, soll das in der Datenbank stehen, damit wir nur noch einen Dump von mySQL machen müssen und die neuen Datensätze dann schneller in die Access DB bekommen

So weit zur Vorgeschichte.
Jetzt ist es so, dass wenn das Formular ausgefüllt ist und zur Übersicht kommt, diese Übersicht quasi der Durchschlag für den Kunden darstellt. In der Papierform ist dort bereits eine Nummer drauf.
Warum ich den Druck an den Eintrag koppeln will ist einfach: Will der Kunde eben dieses Angebot nicht nutzen, und der Händler war voreilig, weil er Zeit sparen wollte und das Formular vorab soweit ausgefüllt hat - hab ich einen überflüssigen Eintrag in der Datenbank.
Der Ausdruck der erfolgt, ist zwinged, da es sich um die Auftragsbestätigung handelt - die ja der Kunde unterschreiben muss. Die wird dann nur noch bei uns abgeheftet.

In meinen Augen sind die Benutzer, die das Formular ausfüllen sollen , "DAUs"... Daher kommt auch nach dem Absenden der Daten an die DB die Danke-Seite, die signalisieren soll: Alle Daten sind da. Entsprechende Transfer-Fehler fange ich in meinem DB Skript ja ab, sodaß es gar nicht soweit kommt, dass er annimmt es wäre alles okay, da er ja auf dem Monitor darauf hingewiesen wird.
Dass er nicht gleich in die DB schreibt, nach Absenden des Formulars hat auch den Grund, dass wenn er zurückgeht um etwaige Rechtschreibfehler zu korrigieren, er ja wieder einen neuen Datensatz anlegen würde. Man muss auch bedenken, dass eine Verzweigung für update und insert an der Stelle schon sinnig wäre, aber da es sich nicht um ein Einmal-Formular wie die Registration in einem Board handelt, verkompliziert das den ganzen Kram für mich noch weiter. Ich hab eh schon keine Ahnung von PHP und dem ganzen Kram und ich würde den am liebsten in die Tonne treten, weil er nicht so funktioniert wie ich es gern hätte :/

Die Vorgaben sind von meinem Chef:
Online formular
Übersicht und Korrekturmöglichkeit und automatische Nummernvergabe
Eintrag in die Datenbank
Emailbenachrichtigung
Internes Formular zum Überprüfen/Ändern der Daten in einem extra Login-Bereich.

Unvollständige Datensätze will ich hingegen nicht. Da ich genau weiß an wem es hängen bleibt die unvollständigen Datensätze rauszulöschen wenns an den Export/Import geht.
 
Hi,

Dort tragen dann die Händler mit den Kunden (oder auch schon vorher) die Daten ein. Wenn er den Aufrag an uns abschließt, soll das in der Datenbank stehen, damit wir nur noch einen Dump von mySQL machen müssen und die neuen Datensätze dann schneller in die Access DB bekommen

Das heißt, auf der Seite mit der Übersicht, die dann noch einmal bestätigt werden muss, befindet sich auch die Druckfunktion. Das würde ich so nicht machen. Pack die Druckfunktion auf die Feedbackseite. Das ist doch auch viel logischer.

So weit zur Vorgeschichte.
Jetzt ist es so, dass wenn das Formular ausgefüllt ist und zur Übersicht kommt, diese Übersicht quasi der Durchschlag für den Kunden darstellt. In der Papierform ist dort bereits eine Nummer drauf.

Man kann eine Abwicklung in Papierform, bei der die beiden Parteien bei 'nem Kaffee zusammensitzen, nicht immer 1:1 in einer Webanwendung umsetzen. Für den Kunden ist es doch logisch völlig nachvollziehbar, wenn er sich seinen "Durchschlag" erst ausdrucken kann, nachdem er den Auftrag auch bestätigt hat.

Man muss auch bedenken, dass eine Verzweigung für update und insert an der Stelle schon sinnig wäre, aber da es sich nicht um ein Einmal-Formular wie die Registration in einem Board handelt, verkompliziert das den ganzen Kram für mich noch weiter. Ich hab eh schon keine Ahnung von PHP und dem ganzen Kram und ich würde den am liebsten in die Tonne treten, weil er nicht so funktioniert wie ich es gern hätte :/

Na ja, ein wenig Arbeit ist das schon, aber so schlimm ist es auch wieder nicht, wenn das Konzept stimmt. Wenn Dein Chef die technischen Erklärungen nicht versteht, musst Du ihm halt einfach mal mit dem schnöden Mammon kommen und ihm erklären, wieviel Entwicklungsaufwand - und damit seine Kohle - eine klitzekleine Änderung an seinen Vorgaben sparen würde.

Unvollständige Datensätze will ich hingegen nicht. Da ich genau weiß an wem es hängen bleibt die unvollständigen Datensätze rauszulöschen wenns an den Export/Import geht.

Das wäre das geringste Problem. Da bräuchtest Du nur ein zusätzliches Statusfeld, das Du setzt, wenn der Auftrag bestätigt wurde. Die nicht bestätigten kannst Du ja automatisiert löschen, z.B. vor dem Export. ;)

LG
 
Man kann eine Abwicklung in Papierform, bei der die beiden Parteien bei 'nem Kaffee zusammensitzen, nicht immer 1:1 in einer Webanwendung umsetzen. Für den Kunden ist es doch logisch völlig nachvollziehbar, wenn er sich seinen "Durchschlag" erst ausdrucken kann, nachdem er den Auftrag auch bestätigt hat.

Ich würde mir zuerst den Vertrag nochmal auf Papier anschauen, durchlesen und verstehen wollen, bevor ich in irgendeiner Form (mündlich oder schriftlich) zustimme. Daher hätte ich sehr wohl was dagegen, wenn ich zuerst abnicken muss und dann erst den Vertrag unterschreiben kann. Käme ja einer Blanko-Untershcrift gleich.

Warum nicht einfach den Datensatz beim ersten Abschicken in die DB aufnehmen, dadurch bekommst du doch die Nummer zurück. Jedes weitere Abschicken erfolgt dann mit Übergabe der Nummer, d.h. du weisst, welcher Datensatz mit Update statt Insert zu bearbeiten ist. Hat im Endeffekt auch den Vorteil, dass man später sieht, welche Anfragen auch wirklich zu einem Vertragsabschluss geführt haben. (Setzt natürlich voraus, dass du ein zusätzliches Datenbankfeld einfügen kannst, das den Status abbildet - Anfrage, Abgeschlossen)
 
Genau das (das Einfügen eines zusätzlichen Feldes) kann ich leider nicht machen, da ich sonst Import/Export Probleme bekomme.

Was genau Händler und dessen Kunde bei nem Kaffee machen oder nicht ist mir eigentlich vollkommen egal. Ich soll ja nur die technische Realisierung übernehmen ;)

Da ja Wochenende war hab ich in der Badewanne liegend nachgedacht wie ich das wohl lösen kann und nun folgendes gemacht:
Der Händler schickt nun sein ausgefülltes Formular ab, kommt auf die Übersicht. Dort kann er von mir aus bleiben bis er dunkelgrau ist. Wenn er sich dann entschieden hat, dass alles okay ist muss er die Daten bestätigen - damit werden sie in die DB geschrieben und die Nummer ausgegeben. Dann kann er auf dem seperaten Button drucken und wird zur Danke-Seite geschickt. Die Buttons für Bestätigung und Drucken sind in PHP eingebettet und werden in Abhänigkeit davon, ob die Daten bereits gesendet wurden, entsprechend gezeigt.
Zwar zwinge ich dem Händler 2x die Übersicht auf, aber es lässt sich wohl nicht vermeiden.
 
Hi,

Ich würde mir zuerst den Vertrag nochmal auf Papier anschauen, durchlesen und verstehen wollen, bevor ich in irgendeiner Form (mündlich oder schriftlich) zustimme. Daher hätte ich sehr wohl was dagegen, wenn ich zuerst abnicken muss und dann erst den Vertrag unterschreiben kann. Käme ja einer Blanko-Untershcrift gleich.

Dazu ist ja eigentlich die Übersicht da, dass man sich alles nochmal anschauen kann, bevor man bestätigt. Wenn ich das richtig verstanden habe, muss der Kunde so oder so das ausgedruckte Formular noch einmal unterschreiben. Also löst das Koppeln des Datenbankeintrages an die Druckfunktion das Problem eines nicht unterschriebenen Formulars sowieso nicht.

WiZDooM hat gesagt.:
Genau das (das Einfügen eines zusätzlichen Feldes) kann ich leider nicht machen, da ich sonst Import/Export Probleme bekomme.

Das kommt darauf an, wie Du Import und Export löst. Das ist doch eigentlich kein großes Problem.

WiZDooM hat gesagt.:
Zwar zwinge ich dem Händler 2x die Übersicht auf, aber es lässt sich wohl nicht vermeiden.

Ich würde den Druckbutton immer noch auf der "Danke"-Seite, vielleicht noch garniert mit einem kleinen Hinweistext, unterbringen.

LG
 
Das kommt darauf an, wie Du Import und Export löst. Das ist doch eigentlich kein großes Problem.

Oh nicht ? Ich sehe den Export von MySQL in MS Access durchaus als ein Problem an... Allein schon wegen dem Datumsfeld -.-

Ich würde den Druckbutton immer noch auf der "Danke"-Seite, vielleicht noch garniert mit einem kleinen Hinweistext, unterbringen.

Hmm, vielleicht hab ich nur einen logischen Fehler, aber wie soll man auf der Danke-Seite eine bereits verlassene Seite ausdrucken?

Ich bezweifel dass der Kunde erst "Ja" sagt und dann nach dem Abschicken durch den Händler plötzlich "Nein" sagt, wenn er das Dokument zur Unterschrift vorgesetzt bekommt.
 
Hi,

Oh nicht ? Ich sehe den Export von MySQL in MS Access durchaus als ein Problem an... Allein schon wegen dem Datumsfeld -.-

Das Problem hat man ja immer, wenn man einen Export für ein anderes DBMS macht. MySQL bietet eine umfangreiche Sammlung an Datums- und Zeitfunktionen, mit denen man einen DateTime-Wert im Format seiner Wahl ausgeben kann. Welches Problem hast Du konkret dabei?

Hmm, vielleicht hab ich nur einen logischen Fehler, aber wie soll man auf der Danke-Seite eine bereits verlassene Seite ausdrucken?

Verbirgt sich hinter Eurem Druckbutton einfach nur ein onclick="window.print();"? Dann geht das natürlich nicht. Ich persönlich mache das so nie, da auf der jeweiligen Seite in den meisten Fällen noch eine Navigation, Header, Footer und sonstiges vorhanden sind, die auf dem Ausdruck nicht erscheinen sollen. Auch ein dunkler Hintergrund z.B. ist beim Drucken ein Ärgernis. Man kann die Seite aber bei Klick auf den Button mit einem eigenen Drucktemplate bzw. -Stylesheet aufrufen und diese dann drucken.

Ich bezweifel dass der Kunde erst "Ja" sagt und dann nach dem Abschicken durch den Händler plötzlich "Nein" sagt, wenn er das Dokument zur Unterschrift vorgesetzt bekommt.

Es ging da mehr um die theoretische Möglichkeit, da procurve meinte, er würde den Vertrag erst auf Papier lesen wollen, bevor er zustimmt. In dem Fall wären aber die Daten ja so oder so schon in der Datenbank. ;)

LG
 
Das Problem hat man ja immer, wenn man einen Export für ein anderes DBMS macht. MySQL bietet eine umfangreiche Sammlung an Datums- und Zeitfunktionen, mit denen man einen DateTime-Wert im Format seiner Wahl ausgeben kann. Welches Problem hast Du konkret dabei?
Das Problem ist, der User soll das Datum als tt.mm.jjjj angezeigt bekommen während in der DB ja das Datum jjjj-mm-tt gespeichert wird.

Verbirgt sich hinter Eurem Druckbutton einfach nur ein onclick="window.print();"? Dann geht das natürlich nicht. Ich persönlich mache das so nie, da auf der jeweiligen Seite in den meisten Fällen noch eine Navigation, Header, Footer und sonstiges vorhanden sind, die auf dem Ausdruck nicht erscheinen sollen. Auch ein dunkler Hintergrund z.B. ist beim Drucken ein Ärgernis. Man kann die Seite aber bei Klick auf den Button mit einem eigenen Drucktemplate bzw. -Stylesheet aufrufen und diese dann drucken.

Ja, das ist richtig. Der Druck wird automatisch mit Javascript angestoßen.
Der Fall Header und Footer erledigt sich dank iFrame von selbst, und eine extra print.css zur Formatierung zwecks Druck exisitert auch ;)

Es ging da mehr um die theoretische Möglichkeit, da procurve meinte, er würde den Vertrag erst auf Papier lesen wollen, bevor er zustimmt. In dem Fall wären aber die Daten ja so oder so schon in der Datenbank. ;)

Richtig.
 
Zurück