nicht angemeldet
Seitenreload
Rolf BHallo Forum,
ich würde gerne einen automatischen Seitenreload machen. Der aber soll 2 Kriterien brücksichtigen:
-
Der Seite soll für einen User, wenn er innerhalb der Seite gescrollt hat, wieder ganz genau an diesen Punkt zurückspringen
-
Der Seitenreload soll ausgesetzt sein,wenn der User zb. gerade ein Formular ausfüllt.
Welche Möglichkeiten des Seitenreload kommen da für mich in Frage und wie gehe ich am besten die Umsetzung der beiden Kriterien an?
Pit
-
Hey,
ich würde gerne einen automatischen Seitenreload machen. Der aber soll 2 Kriterien brücksichtigen:
-
Der Seite soll für einen User, wenn er innerhalb der Seite gescrollt hat, wieder ganz genau an diesen Punkt zurückspringen
-
Der Seitenreload soll ausgesetzt sein,wenn der User zb. gerade ein Formular ausfüllt.
Welche Möglichkeiten des Seitenreload kommen da für mich in Frage und wie gehe ich am besten die Umsetzung der beiden Kriterien an?
Man könnte vieles machen, ein Seitenreload ist aber nicht Benutzerfreundlich. Wenn du dir vorstellst du liest irgendwo einen Artikel oder dergleichen und dann läd sich die Seite von selbst neu, empfindest du das sicher als störend. Auch wenn die Seite dann wieder an der selben Scroll position ist, was nicht heißt, dass der Nutzer das gleiche sieht, weil der neu geladene Content möglicherweise kürzer oder länger ist.
Du solltest dir eher Gedanken über eine Contentmanipulation (hinzufügen/entfernen) via Javascript machen.
Gruß
Jo-
Hi jo,
Du solltest dir eher Gedanken über eine Contentmanipulation (hinzufügen/entfernen) via Javascript machen.
Das wäre sicher der Königsweg, da geb ich Dir recht…
Pit
-
-
Tach!
Wie immer geht man bei solchen Problemen daran, die Teilfragen zu stellen, die man auf dem Weg zur Lösung braucht.
- Der Seite soll für einen User, wenn er innerhalb der Seite gescrollt hat, wieder ganz genau an diesen Punkt zurückspringen
Wie bekommt man die aktuelle Scrollposition im Browser raus? Wie speichert man Werte im Browser zum Wiederverwenden zwischen Requests?
- Der Seitenreload soll ausgesetzt sein,wenn der User zb. gerade ein Formular ausfüllt.
Definiere "User füllt ein Formular aus". Wie erkennst du (erstmal logisch und noch nicht programmiertechnisch), dass das der Nutzer gerade macht? Reicht bereits "User hat ein Formularfeld aktiviert"? Oder soll noch eine Endebedingung wirken, à la "User ist x Zeiteinheiten lang inaktiv", oder "User klickt irgendwo anders auf die Seite"?
Je nachdem, was hier die Anworten sind, musst du dir überlagen, welche technischen Schritte, Abläufe und Wechselbeziehungen notwendig sind, um das Szenario zu bedienen. Timeouts und Klickerkennung (und ähnliches, wie onblur) kommen da sicher ins Spiel.
Lösungsrichtungen für die ersten beiden Fragen:
Wie bekommt man die aktuelle Scrollposition im Browser raus?
Da gibt es Elementeeigenschaften mit scroll im Namen.
Wie speichert man Werte im Browser zum Wiederverwenden zwischen Requests?
Dazu gibt es zum Beispiel den Local Storage oder den Session Storage. In deinem Fall ist wohl letzterer angebracht.
dedlfix.
-
Tach!
Wie immer geht man bei solchen Problemen daran, die Teilfragen zu stellen, die man auf dem Weg zur Lösung braucht.
Achja, und die wichtigste Frage ist: Ist das überhuapt eine Lösung für das eigentliche Problem oder holt man sich damit nur mehr Probleme ins Haus als man ohne diese Lösung hätte.
dedlfix.
-
Hi dedlfix,
Wie immer geht man bei solchen Problemen daran, die Teilfragen zu stellen, die man auf dem Weg zur Lösung braucht.
Achja, und die wichtigste Frage ist: Ist das überhuapt eine Lösung für das eigentliche Problem oder holt man sich damit nur mehr Probleme ins Haus als man ohne diese Lösung hätte.
Erstens danke für Dein Post und das aufsplitten der Lösung in Teilschritte. Und ja, ich gebe Dir weiterhin recht, dass ich mir inzwischen (dank an Jo) die Frage stelle, was eigentlich komplizierter wird.
muss denn die gesamte Seite oder sollen nur Teile davon aktualisiert werden? (@Robert)
Ich skizziere das "Problem" nochmal etwas genauer:
Es handelt sich um eine Tabelle, deren Zellen jeweils eine ID haben. Jede Zelle kann mehrere Einträge haben, sowie einer Css-Klasse angehören. Die Tabelle kann von mehrern Usern mit Zelleneinträgen befüllt sowie editiert/gelöscht werden. Der User, der einen Eintrag vor- oder wegnimmt, erhält ohnehin einen Reload der Seite. Aber die anderen user hinken dem nun hinterher…
Pit
-
Hallo Pit,
Ich skizziere das "Problem" nochmal etwas genauer:
Es handelt sich um eine Tabelle, deren Zellen jeweils eine ID haben. Jede Zelle kann mehrere Einträge haben, sowie einer Css-Klasse angehören. Die Tabelle kann von mehrern Usern mit Zelleneinträgen befüllt sowie editiert/gelöscht werden. Der User, der einen Eintrag vor- oder wegnimmt, erhält ohnehin einen Reload der Seite. Aber die anderen user hinken dem nun hinterher…
das klingt nach Verwendung von WebSockets oder AJAX. Und natürlich musst du Sorge tragen, dass nicht zwei Edits auf die gleiche Zelle gleichzeitig stattfinden.
Viele Grüße
Robert -
Tach!
Es handelt sich um eine Tabelle, deren Zellen jeweils eine ID haben. Jede Zelle kann mehrere Einträge haben, sowie einer Css-Klasse angehören. Die Tabelle kann von mehrern Usern mit Zelleneinträgen befüllt sowie editiert/gelöscht werden. Der User, der einen Eintrag vor- oder wegnimmt, erhält ohnehin einen Reload der Seite. Aber die anderen user hinken dem nun hinterher…
Nunja, dann gibt es die Möglichkeit des periodischen Aktualisierens. Das kann man brutal mit einem Seiten-Reload machen, aber auch weniger hart durch Austausch der betroffenen Datensätze. (Zusatzfrage, was passiert mit dem Datensatz, den einer gerade bearbeitet, während ein anderer die Bearbeitung abgeschlossen hat und nun eine Aktualisierung ansteht?)
Neben dem periodischen Aktualisieren gibt es auch noch die Möglichkeit, dass der Server über Änderungen informiert. Dazu muss ein Rückkanal vom Browser zum Server ständig offen sein, über den der Server Nachrichten schicken kann. Üblicherweise erfolgt das heutzutage über Websocket. Es gibt auch Systeme wie SignalR, die die Niederungen der Kommunikation wegabstrahieren und sich programmiertechnisch wie ein Funktionsaufruf anfühlen. Besonders wenn der IIS und ASP.NET MVC auf Serverseite zum Einsatz kommen. Ich weiß grad nicht, was du für ein System hast. Der allgemeine Name für solche Systeme ist RPC (Remote Procedure Call) oder besonders im Webumfeld auch Push Notification.
dedlfix.
-
Hallo dedlfix,
(Zusatzfrage, was passiert mit dem Datensatz, den einer gerade bearbeitet, während ein anderer die Bearbeitung abgeschlossen hat und nun eine Aktualisierung ansteht?)
Steht dann auch an, richtig.
Neben dem periodischen Aktualisieren gibt es auch noch die Möglichkeit, dass der Server über Änderungen informiert.
Kann ich leider vergessen. Bietet mein managed Server nicht.
Ich könnt natürlich auch dem User per Ajax anzeigen, dass sich Tabelleneinträge verändert haben, dann kann er selbst entscheiden, ob er reloaden möchte. Der Nachteil ist, er muß dann hierfür aktiv werden. Kein Problem, wenn man vorm Rechner sitzt. Aber was mit denen, die die Tabelle nur auf einem Monitor im Hintergrund sehen, aber weder Tastatur noch Maus vor sich haben?
Also doch die betreffenden Zellen über Ajax neu beladen...
Pit
-
-
hi,
Ich skizziere das "Problem" nochmal etwas genauer:
Es handelt sich um eine Tabelle, deren Zellen jeweils eine ID haben. Jede Zelle kann mehrere Einträge haben, sowie einer Css-Klasse angehören. Die Tabelle kann von mehrern Usern mit Zelleneinträgen befüllt sowie editiert/gelöscht werden.
Da wo diese Tabelle gespeichert wird, wäre dafür zu sorgen, daß Änderungen nur nacheinander stattfinden dürfen, insbesondere dann, wenn es Abhängigkeiten gibt wie z.B. bei einem Konto wo jede Transaktion auf dem alten Saldo aufsetzt und einen neuen Saldo erzeugt. Auf die Tabelle selbst wäre ein exclusive lock zu setzen und ggf. wird jede Änderung protokolliert.
Der User, der einen Eintrag vor- oder wegnimmt, erhält ohnehin einen Reload der Seite. Aber die anderen user hinken dem nun hinterher…
Dieses Problem wirst Du auch mit automatisierten Reloads nicht lösen. Nichts spricht jedoch dagegen, den Benutzer darauf hinzuweisen, daß sich Daten anderweitig geändert haben wenn er auf Speichern klickt. MfG
-
Hi pl,
Dieses Problem wirst Du auch mit automatisierten Reloads nicht lösen. Nichts spricht jedoch dagegen, den Benutzer darauf hinzuweisen, daß sich Daten anderweitig geändert haben wenn er auf Speichern klickt. MfG
Na das sowieso. Aber ich meinte jetzt eher die User, die nicht klicken...die auf gar nichts klicken. Die hinken hinterher, meinte ich.
Pit
-
hi Pit
Dieses Problem wirst Du auch mit automatisierten Reloads nicht lösen. Nichts spricht jedoch dagegen, den Benutzer darauf hinzuweisen, daß sich Daten anderweitig geändert haben wenn er auf Speichern klickt. MfG
Na das sowieso. Aber ich meinte jetzt eher die User, die nicht klicken...die auf gar nichts klicken. Die hinken hinterher, meinte ich.
Das werden sie immer, auch dann wenn die Seite automatisch neulädt. Selbst wenn mit Ajax Änderungen direkt ins DOM gepflanzt werden kann das unangenehm werden wenns nämlich genau da passiert wo gerade editiert wird -- da ist das was da gerade eingegeben wurde weg und zwar ganz weg.
Fazit: Mach Dir um das Reload keine Gedanken. Das machen die Anwender von selbst. MfG
-
Hallo pl,
stimmt schon, ein Auto-Update müsste die vom User aktuell editierte Zelle gesondert behandeln. Die Frage ist nur, wie? Weil: Wenn ich beim Editieren überholt worden bin, dann ist mein aktueller Edit ohnehin problematisch, weil er auf falschen Grundlagen basiert. Resolve-Strategien für Edit-Kollisionen gibt's reichlich, und ob ein optimistisches Sperrverfahren hier sinnvoll ist, hängt von der konkreten Fachlichkeit ab. Sprich: wie hoch ist die Wahrscheinlichkeit, dass zwei User die gleiche Zelle editieren? Ist sie gering, dann kann man einfach Editieren lassen und demjenigen, der als zweites Speichert, ein "Ätsch" melden. Der Background-Update kann diese konkurrierende Änderung ebenfalls feststellen und dem User mitteilen: Deine Bearbeitung ist obsolet [OK] - und nach Klick auf OK isse dann weg.
Die aufwändigste Lösung ist dann, dem überholten User beim SPEICHERN anzuzeigen, dass er überholt wurde und wie die neuen Daten aussehen. In einem Merge-Dialog kann man dann die Daten des Überholers sehen und die eigenen Daten, und dann den konsolidierten Stand eingeben (so wie man es beim Checkin in GIT oder anderen Sourcecontrol-Systemen tut). Je nach Art der Daten kann der Server ggf. sogar automatisch mergen. Das ist je nach Daten alles andere als trivial. Ob diese Lösung sinnvoll ist, hängt wieder von der jeweiligen Fachlichkeit ab.
Ist das nicht machbar oder tolerierbar, dann kommt noch eine pessimistische Sperrstrategie in Betracht. Aber nicht auf Tabellen-Ebene, sondern auf Zellen-Ebene, d.h. sobald der User mit dem Editieren einer Zelle beginnt, gibt's einen Ajax-Request an den Server, der ihm die Zelle reserviert. Und der Edit-Mode geht erst an, wenn dieser Request mit "Erfolg" beantwortet wird.
Nun hat man aber ein anderes Problem: Was macht man mit vergessenen Locks? Z.B. weil ein User zu Editieren begonnen hat und dann irgend ein Spectre ihm einen BSOD beschert hat. D.h. wenn ich EDIT drücke und ein älterer Lock da ist (was „älter“ ist, hängt von der typischen Edit-Dauer ab), muss ich die Möglichkeit haben, diesen Lock zu übergehen. Und wenn ich der User bin, dessen Lock da gerade geknackt wurde, muss ich natürlich im Rahmen des ohnehin stattfindenden Background-Update (oder spätestens beim Speichern) ein Signal erhalten, dass mein Edit leider für den Popo war und ich jetzt in die Tischkante beißen darf (oder in den Finger von User XYZ, der meinen Lock gemopst hat).
Ohne JavaScript ist das aber alles nicht machbar, in dem Fall hilft nur eine eigene Edit-Seite, die nach "Speichern" zur Tabelle zurückkehrt.
Rolf
--
sumpsi - posui - clusi
-
-
-
-
-
-
Hallo Pit,
muss denn die gesamte Seite oder sollen nur Teile davon aktualisiert werden?
Viele Grüße
Robert-
Hallo Pit,
muss denn die gesamte Seite oder sollen nur Teile davon aktualisiert werden?
Hallo Robert,
ich habe Deine hier beantwortet.
Pit
-