Multi-Seiten-Formulare über Sessions kompatibel zu multiplen Fenstern/Tabs machen

robo47 · 19.12.2009, 10:00

Ich wollte mal fragen ob es da noch andere Ansätze gibt als meinen aktuellen die vielleicht irgendwelche weiteren Vorteile haben. Bis jetzt ist das auch noch nicht in die Praxis umgesetzt sondern ein rein theorhetischer Ansatz.

Es geht darum, dass es nicht zu einem überschreiben der Daten kommen soll wenn ein Formular gleichzeitg in mehreren Fenstern/Tabs von ein und der selben Person (Gleiche Session) ausgefüllt wird, er also synchron mehrere Tabs offen haben kann und die Formulare bis zum Ende ausfüllen kann.

Ich habe ein Formular das über mehrere Seiten geht, auf der ersten Seite wird jedes mal ein Token generiert der via hidden Field UND als GET-parameter weitergegeben wird.

Die Speicherung der Formular-Daten in der Session findet dann in

$_SESSION['formularX'][$token] ....

statt.

Reine GET-Requests ohne Token (via GET) auf Seiten > 1 werden natürlich automatisch wegen des fehlenden Tokens mit einer Fehlermeldung und einem Link auf Seite 1 beantwortet.
Der Wechsel zwischen Seiten ist durch den zusätzlichen GET-parameter möglich, man braucht also keine extra vor oder zurück-Buttons die post-requests ausführen.

Ein Wechsel der Seite über den "Zurück-Button" des Browsers ist dadurch möglich, dass eben der Token auch via GET übergeben wird und die erste Seite "cheatet" hier indem sie sich selbst mit angehängtem GET-parameter neu lädt wenn der Token nicht vorhanden oder ungültig ist, weil für den token via hidden-field wären ja POST-requests nötig und ein Zurück im Browser auf die erste Seite die selbst nicht via POST sondern GET erreicht wurde gäbe es den Token logischerweise nicht.

Wird eine Seite mit Token via GET aufgerufen der nicht in der Session existiert wird ein Fehler ausgegeben und ein Link auf die erste Seite des Formulars ausgegeben.

Aufgrund möglicherweise großer Formular ist die gültigkeit der Session ausreichend hoch anzusetzen.

Desweiteren denke ich über eine Sicherung der Daten nach, dass bei Usern die einen Login verwendet haben in der DB Token + Startzeit + Daten nach jeder Seite gespeichert werden und auf einer Extra Seite der User die Möglichkeit hat (auch nach einem Logout/Login wenn die Daten nicht mehr in der Session existieren) alte "Sessions" quasi zu laden um dort weiterzumachen.

Ajax / Echtzeit-Validation steht als Feature auch auf der Liste, aber da das System natürlich auch ohne Javascript funktionieren muss bleibt das erstmal aussen vor, für die eingeloggten User wird das speichern der Daten in der Datenbank eventuell einstellbar sein, dass via ajax im hintergrund alle Minute die Daten in der DB gespeichert werden.

Gibt es irgendwas usability-technisches oder so was da noch auf der Strecke bleibt bei dem Ansatz ?

Der User kann sich eigentlich nur noch selbst Daten "überschreiben" wenn man eine Url zu einer Seite mit Token in einem 2ten Fenster/Tab öffnet und er nicht richtig hinschaut, da es auch eine Statusbox gibt wo man sieht welche Seiten bereits ausgefüllt sind (ROT -> nichts ausgefüllt, gelb teilweise ausgefüllt oder mit Werten die nicht erlaubt sind [muss ermöglicht werden da die formulare teilweise nur schnellen notizen gefüllt werden und später fertig gemacht werden, die Tabs also offen bleiben], grün -> alles passend und gültig ausgefüllt).

mepeisen · 20.12.2009, 11:11

Also für mich bleibt da aus Usability-Sicht nichts übrig. Der Standard-Fall (Formular Straight-Forward) ist abgedeckt) und der besondere Fall (Bearbeitung mehrerer Formularpages in mehreren Fenstern).
Das, was du eventuell andenken solltest, dass manche Formularseiten erst dann gefüllt werden können, wenn in der vorherigen Werte eingetragen sind. Beispielsweise ein Formular zum Festlegen einer Datenbank-Verbindung. Als erstes wird der Treiber ausgewählt und auf der zweiten Seite abhängig vom Treiber die Verbindungsdaten (z.B. MySQL vs. SQLite). Will sagen: Dort könnte es evtl. schwierig werden mit der Unterstützung von mehreren Browserfenstern.

dr.e. · 20.12.2009, 12:28

Hallo Robo,

webwork im Java-Bereich löst das in der Tat mit einem Session-Kontext. Dort heißt das, was du mit dem eigenen Session-Array-Offset andeutest "pageflow context". Das ist ein serialisierbares Model, das in der Session abgelegt wird und jeweils die Informationen deines Workflows abbildet. Die Konfiguration selbst wird an Hand einer XML-Datei vorgenommen (Steps) und richtet sich nach der Implementierung der Actions.

Zur Identifikation der Schritte wird eine Pageflow-ID genutzt, die jeweils gleich sein muss (sofern gewünscht) oder auch unterschiedlich sein darf. Da der Kontext an der Session hängt, ist es möglich, mehrere Nutzer und innerhalb eines Nutzers mehrere Browser-Fenster zu unterstützten. Optional kannst du bei Webwork Interceptoren definieren, die vor einer Action im Stack ausgeführt werden und z.B. die Pageflow-ID prüfen.

Ungefähr so würde ich das auch umsetzen, denn einfache Session-Offsets sind doch etwas untypisiert.

robo47 · 20.12.2009, 16:52

Ich denke mal mit dem PageFlow Contenxt in Java werde ich mir die Tage mal noch genauer anschauen, aber wie es aussieht hat der potentielle Kunde das "Interesse" verloren, weil es mehr 10 Zeilen Code in die vorhandene App einfügen ist

dr.e. · 20.12.2009, 20:04

Hmm, schade auch. Das ist an sich ein sehr spannendes Thema. Mehr dazu findest du unter WebWork - WebWork - WebWork

robo47 · 20.12.2009, 20:51

Danke für den Link.

Interessant ist das ganze auf jeden Fall, aber das ist so viel was interessant ist ...

Meine Todo mit interessanten Sachen neben dem Studium quillt eh über

Wird langsam Zeit für den 48 Stunden Tag oder die 14-Tage Woche bei Beibehaltung von 5 Werktagen

Themen-Optionen
Druckbare Version zeigen Jemanden per E-Mail auf dieses Thema hinweisen
Thema bewerten
Thema bewerten:

19.12.2009, 10:00
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	Multi-Seiten-Formulare über Sessions kompatibel zu multiplen Fenstern/Tabs machen Ich wollte mal fragen ob es da noch andere Ansätze gibt als meinen aktuellen die vielleicht irgendwelche weiteren Vorteile haben. Bis jetzt ist das auch noch nicht in die Praxis umgesetzt sondern ein rein theorhetischer Ansatz. Es geht darum, dass es nicht zu einem überschreiben der Daten kommen soll wenn ein Formular gleichzeitg in mehreren Fenstern/Tabs von ein und der selben Person (Gleiche Session) ausgefüllt wird, er also synchron mehrere Tabs offen haben kann und die Formulare bis zum Ende ausfüllen kann. Ich habe ein Formular das über mehrere Seiten geht, auf der ersten Seite wird jedes mal ein Token generiert der via hidden Field UND als GET-parameter weitergegeben wird. Die Speicherung der Formular-Daten in der Session findet dann in $_SESSION['formularX'][$token] .... statt. Reine GET-Requests ohne Token (via GET) auf Seiten > 1 werden natürlich automatisch wegen des fehlenden Tokens mit einer Fehlermeldung und einem Link auf Seite 1 beantwortet. Der Wechsel zwischen Seiten ist durch den zusätzlichen GET-parameter möglich, man braucht also keine extra vor oder zurück-Buttons die post-requests ausführen. Ein Wechsel der Seite über den "Zurück-Button" des Browsers ist dadurch möglich, dass eben der Token auch via GET übergeben wird und die erste Seite "cheatet" hier indem sie sich selbst mit angehängtem GET-parameter neu lädt wenn der Token nicht vorhanden oder ungültig ist, weil für den token via hidden-field wären ja POST-requests nötig und ein Zurück im Browser auf die erste Seite die selbst nicht via POST sondern GET erreicht wurde gäbe es den Token logischerweise nicht. Wird eine Seite mit Token via GET aufgerufen der nicht in der Session existiert wird ein Fehler ausgegeben und ein Link auf die erste Seite des Formulars ausgegeben. Aufgrund möglicherweise großer Formular ist die gültigkeit der Session ausreichend hoch anzusetzen. Desweiteren denke ich über eine Sicherung der Daten nach, dass bei Usern die einen Login verwendet haben in der DB Token + Startzeit + Daten nach jeder Seite gespeichert werden und auf einer Extra Seite der User die Möglichkeit hat (auch nach einem Logout/Login wenn die Daten nicht mehr in der Session existieren) alte "Sessions" quasi zu laden um dort weiterzumachen. Ajax / Echtzeit-Validation steht als Feature auch auf der Liste, aber da das System natürlich auch ohne Javascript funktionieren muss bleibt das erstmal aussen vor, für die eingeloggten User wird das speichern der Daten in der Datenbank eventuell einstellbar sein, dass via ajax im hintergrund alle Minute die Daten in der DB gespeichert werden. Gibt es irgendwas usability-technisches oder so was da noch auf der Strecke bleibt bei dem Ansatz ? Der User kann sich eigentlich nur noch selbst Daten "überschreiben" wenn man eine Url zu einer Seite mit Token in einem 2ten Fenster/Tab öffnet und er nicht richtig hinschaut, da es auch eine Statusbox gibt wo man sieht welche Seiten bereits ausgefüllt sind (ROT -> nichts ausgefüllt, gelb teilweise ausgefüllt oder mit Werten die nicht erlaubt sind [muss ermöglicht werden da die formulare teilweise nur schnellen notizen gefüllt werden und später fertig gemacht werden, die Tabs also offen bleiben], grün -> alles passend und gültig ausgefüllt). __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework


Mister Ad PHP Code Flüsterer Registriert seit: 21.08.2005 Beiträge: 4682 PHP-Kenntnisse: Fortgeschritten

20.12.2009, 11:11
mepeisen Erfahrener Benutzer Registriert seit: 21.12.2004 Beiträge: 5.245 PHP-Kenntnisse: Fortgeschritten	Also für mich bleibt da aus Usability-Sicht nichts übrig. Der Standard-Fall (Formular Straight-Forward) ist abgedeckt) und der besondere Fall (Bearbeitung mehrerer Formularpages in mehreren Fenstern). Das, was du eventuell andenken solltest, dass manche Formularseiten erst dann gefüllt werden können, wenn in der vorherigen Werte eingetragen sind. Beispielsweise ein Formular zum Festlegen einer Datenbank-Verbindung. Als erstes wird der Treiber ausgewählt und auf der zweiten Seite abhängig vom Treiber die Verbindungsdaten (z.B. MySQL vs. SQLite). Will sagen: Dort könnte es evtl. schwierig werden mit der Unterstützung von mehreren Browserfenstern. __________________ www.php-maven.org PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks Twitter @ https://twitter.com/#!/mepeisen und Facebook @ http://t.co/DZnKSUih

20.12.2009, 12:28
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hallo Robo, webwork im Java-Bereich löst das in der Tat mit einem Session-Kontext. Dort heißt das, was du mit dem eigenen Session-Array-Offset andeutest "pageflow context". Das ist ein serialisierbares Model, das in der Session abgelegt wird und jeweils die Informationen deines Workflows abbildet. Die Konfiguration selbst wird an Hand einer XML-Datei vorgenommen (Steps) und richtet sich nach der Implementierung der Actions. Zur Identifikation der Schritte wird eine Pageflow-ID genutzt, die jeweils gleich sein muss (sofern gewünscht) oder auch unterschiedlich sein darf. Da der Kontext an der Session hängt, ist es möglich, mehrere Nutzer und innerhalb eines Nutzers mehrere Browser-Fenster zu unterstützten. Optional kannst du bei Webwork Interceptoren definieren, die vor einer Action im Stack ausgeführt werden und z.B. die Pageflow-ID prüfen. Ungefähr so würde ich das auch umsetzen, denn einfache Session-Offsets sind doch etwas untypisiert. __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

20.12.2009, 16:52
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	Ich denke mal mit dem PageFlow Contenxt in Java werde ich mir die Tage mal noch genauer anschauen, aber wie es aussieht hat der potentielle Kunde das "Interesse" verloren, weil es mehr 10 Zeilen Code in die vorhandene App einfügen ist __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework

20.12.2009, 20:04
dr.e. Moderator und Wett-König Registriert seit: 21.05.2008 Beiträge: 3.657 PHP-Kenntnisse: Fortgeschritten	Hmm, schade auch. Das ist an sich ein sehr spannendes Thema. Mehr dazu findest du unter WebWork - WebWork - WebWork __________________ Viele Grüße, Dr.E. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1. Think about software design before you start to write code! 2. Discuss and review it together with experts! 3. Choose good tools (-> Adventure PHP Framework (APF))! 4. Write clean and reusable software only! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

20.12.2009, 20:51
robo47 Moderator Registriert seit: 03.09.2004 Beiträge: 11.792 PHP-Kenntnisse: Fortgeschritten	Danke für den Link. Interessant ist das ganze auf jeden Fall, aber das ist so viel was interessant ist ... Meine Todo mit interessanten Sachen neben dem Studium quillt eh über Wird langsam Zeit für den 48 Stunden Tag oder die 14-Tage Woche bei Beibehaltung von 5 Werktagen __________________ robo47.net - Blog, Codeschnipsel und mehr \| Caching-Klassen und Opcode Caches in php \| Robo47 Components - PHP Library extending Zend Framework