Wikipedia:Technik/Baustellen/Speicher-Button-Aktionen

Überlegungen zum Speichern-Button beim Bearbeiten von Seiten usw.

Es wäre zuweilen wünschenswert, die Aktivität dieses Buttons mit JavaScript zu koppeln. Individuelle Hook-Funktionen (emacs/manual) könnten definiert werden, die standardisierte und ausgetestete Basis-Funktionen nutzen.

Vier Fälle sind zu unterscheiden:

1. before-save-hook
   Ausführung unmittelbar vor dem Speichern, ohne dass Nutzer noch einmal interaktiv etwas am Text verändern oder eine jetzt automatisch vorgenommene Veränderung bestätigen könnten.
2. after-save-hook
   Nachdem die Abspeicherung abgeschlossen wurde, soll eine andere Aktivität gestartet werden.
3. Umlenkung
   Der Button soll mit einer anderen als der Speicher-Funktion verknüpft werden.
4. Deaktivierung
   Der Button soll deaktiviert werden (bis ein bestimmter Zustand eingetreten ist).

Risiken

• Ein Risiko beim Eingriff in den Speichern-Button besteht darin, dass nicht-standardkonform arbeitende Browser ungeschickte Eingriffe in die Event-Queue nicht oder nicht immer richtig verarbeiten könnten und Benutzer mit derartigen Browsern nie wieder eine Seite abspeichern können, weil ihr Speichern-Button nicht mehr geht und der stundenlange Edit futsch ist.
  • Wenn der Speichern-Button nicht mehr richtig funktioniert, können (mit Gadget angemeldete) Benutzer nicht einmal auf FzW die Frage stellen, was sie tun sollen (Einfache Erste Hilfe: Im Browser JS deaktivieren).
• Man muss sich der Gefahr des Datenverlustes bewusst sein und durch entsprechende Mechanismen und ausgiebiges Testen diesen soweit möglich ausschließen. Robuste und gut nachvollziehbare Programmierung ist erforderlich.
• Das Risiko muss in angemessenem Verhältnis zum Nutzen stehen; was als allgemeines Gadget für alle Benutzer zu heikel wäre, könnten fortgeschrittene Anwender mit aktuellen Browsern und Wissen um das Verhalten in Problemsituationen einsetzen.

before-save-hook

Mit dem Klicken auf den Speicher-Button soll unmittelbar vor dem Speichern eine automatische Veränderung von Bearbeitungsfeld (oder Z Q oder minoredits) erfolgen, ohne dass Nutzer noch einmal interaktiv etwas am Text verändern oder eine jetzt automatisch vorgenommene Veränderung bestätigen könnten.

Nicht nur das Klicken mit der Maus, sondern auch die Auslösung über Tastaturkürzel und Enter bei Focus muss zum gleichen Effekt führen.

Drei Lösungsansätze:

• Mit jQuery-Funktionen wie .bind() und .delegate() lässt sich die Button-Aktion überlagern und ersetzen. Dabei ist aber die Reihenfolge wichtig: Eine Umformung des Textes im Bearbeitungsfeld kann etwas dauern; werden alle Events gleichzeitig gestartet, dann ist das Formular bereits beim Server angekommen, bevor das Bearbeitungsfeld aktualisiert wurde.
• Mit DOM-Funktionen wie .stopPropagation() und .preventDefault() lässt sich die Event-Kette unmittelbar umbauen; vorausgesetzt dass der Browser das bereits so kennt und versteht. Ein gefahrengeneigter Weg.
• Der sichtbare Button kann gegen einen anderen ausgetauscht werden. Am unterschiedlich gestalteten Button sieht der Anwender, dass eine besondere Zusatzfunktionalität damit verbunden ist. Der Sonder-Button klickt zum Schluss den unsichtbaren, ansonsten unveränderten regulären Button an: Umlenkung.

after-save-hook

Es kann für Spezialaufgaben wünschenswert sein, nach tatsächlich abgeschlossener Speicherung basierend auf der geänderten Seite etwas auszuführen; einen Index zu aktualisieren usw.

Die Seite, auf der die Speicherung ausgelöst wurde, wird anschließend komplett neu vom Server aufgebaut. Kein vor der Speicherung auf der Seite aktives Skript kann über den Neuaufbau hinaus fortgeführt werden; auch laufende API-Aktionen führen kein callback mehr aus.

Drei Lösungsansätze:

• view
  Nach der Speicherung kommt man zur action=view. Diese könnte man damit koppeln, dass per API abgefragt wird, ob unmittelbar zuvor von diesem Benutzer gespeichert wurde. – Da bei jeder action=view ausgeführt, wäre das zunächst extrem ineffizient.
• LocalStorage
  Alle aktuell eingesetzten Browser unterstützen die sogenannten Super-Cookies, die auch über eine Sitzung hinaus erhalten bleiben.
  • Fortgeschrittene Benutzer könnten für Sonderaufgaben eine Art Event-Queue in einem Super-Cookie einrichten:
    TimestampEarliest TimestampExpire JS-Code
    Wenn der Benutzer auf eine bestimmte Seite (etwa Beo) kommt, würde die Liste ausgewertet werden; für diejenigen Einträge, auf die in diesem Moment das Timestamp-Intervall zutrifft, würde der Code ausgeführt (böses eval) und der Eintrag entfernt werden. Was nicht in diesem Intervall abgearbeitet worden war, bleibt zur manuellen Bearbeitung stehen.
  • Kenntnisse der Eingeweide des Browsers sind erforderlich. Überwachung ist nötig, es bestehen mehrfache Sicherheitsrisiken.
• Session-Cookie
  Die SeitenID der für die Hook-Funktion vorgesehenen Seite kann in einem Sitzungs-Cookie abgelegt werden, dessen Name das Schlüsselwort für die Hook-Funktion enthält. Nun kann in dem auf die Speicherung folgenden view (bei jedem Ansehen einer Seite) auf die Existenz eines solchen Cookies geprüft werden; die enthaltene SeitenID muss mit der aktuellen Seite übereinstimmen, um Konflikte zu vermeiden. Ein maximales Alter von 60 Sekunden sollte ausreichen; spätestens mit Ende der Sitzung ist der Cookie obsolet. Die Ausführung muss unmittelbar erfolgen können; ein Abwarten von Replag wie bei einer Event-Queue im LocalStorage wäre nicht so dauerhaft möglich, die Kombination beider Ansätze ist aber denkbar.

Umlenkung

Der sichtbare Button kann gegen einen anderen ausgetauscht werden. Am unterschiedlich gestalteten Button sieht der Anwender, dass eine besondere Zusatzfunktionalität damit verbunden ist.

• Der normale Speicher-Button soll erst in dem Moment unsichtbar geschaltet werden, in dem der zusätzliche (an gleicher Stelle im GUI liegende) Extra-Button ordnungsgemäß aufgebaut und eingefügt wurde und dies gegengecheckt worden war.
• Der Sonder-Button führt seine eigenen Aktivitäten mit eigenem Skript aus und wird mit diesen ohne Besonderheiten verknüpft.
• Der Sonder-Button klickt zum Schluss den unsichtbaren, ansonsten unveränderten regulären Button an.

Deaktivierung

Relativ simpel lässt sich der Button auf disabled schalten. Hoffentlich wird er auch wieder aktiviert, wenn die Bedingungen erfüllt sind.

Bekannte ähnliche Anwendungen

• Benutzer:Perhelion/signing – Erinnern an Signatur auf bestimmten Seiten
• /Baustellen/Warnung wenn Zusammenfassung fehlt
• Benutzer:ParaDox/monobook/VirtualReferences.js
• fileAdm #trans.bot.finish – Zweitbutton; #wpSave unsichtbar
• pl:MediaWiki:Gadget-edit-summary-warning.js

Frühere Diskussionen

• Wikipedia:Technik/Skin/Werkstatt/Archiv/2011 #Speicher-Button deaktivieren