Wikipedia:Technik/Skin/JS/Gadget

Vom Benutzerskript zum Gadget

Diese Projektseite stellt mit der Zielrichtung eines Tutorials dar, wie sich aus den ersten eigenen Programmzeilen eine projektweit einsetzbare Software entwickeln kann.

Erste Phase

Man schreibt etwas, das man nur allein benutzen möchte.

Angebot an alle Benutzer

Wer sein Skript für so gelungen hält, dass es anderen Benutzern zur Verfügung gestellt werden soll, kann Reklame dafür machen:

Skin/Benutzerskripte

Nun sollte es einige Qualitätskriterien erfüllen:

Robuste Funktionsweise.
Keine schädlichen Wirkungen; falls doch eine Fehlfunktion: Baldige Abhilfe.
Gesonderte Dokumentationsseite als Wikitext mit konkreten Informationen zur Benutzung, Wirkung, Nebenwirkungen – ein Verweis auf einige Kommentarzeilen im Skript genügt nicht.
Keine globalen Variablen mehr.
Syntax-Analyse findet keine vermeidbaren Schwächen.
"use strict";

Die Verantwortung teilen sich Anbieter und Anwender.

Helferlein (Gadget)

Nur eine kleine Auswahl von besonders häufig benötigten Werkzeugen kann allen Benutzern angeboten werden.

Beim Gadget übernimmt die Gemeinschaft eine große Mitverantwortung für die ordnungsgemäße Funktion. Hier gilt zusätzlich:

Die Einbindung durch Benutzer ist durch Ankreuzen in der Benutzer-Einstellung Helferlein vereinfacht.
Eine Veränderung ist nur durch Oberflächen-Administratoren möglich.
Gadgets werden immer in der aktuellen Form eingebunden (unterschiedliche URL); Leeren des Browser-Cache ist nach Veränderungen nicht erforderlich.
Die Vereinbarung erfolgt unter MediaWiki:Gadgets-definition. Auf MediaWiki/Änderungen könnte das Skript angeboten werden.
Alle neuen Gadgets müssen für das Laden mit ResourceLoader vorbereitet sein.
Die Funktion muss für eine sehr große Zahl von Benutzern sinnvoll sein. Ansonsten werden Definitionsseite und Einstellungen zu unübersichtlich, und Wartung und Pflege sind kaum noch zu leisten. Sind ursprüngliche Autoren nicht mehr aktiv, sollen andere die Funktionalität erhalten.
Mit Übergabe an die Community übernehmen die Oberflächen-Administratoren und die sie unterstützenden Hilfskräfte die Verantwortung für die ewige Bereitstellung und korrekte Funktion und dauerhafte Pflege. Die Programmierung muss deshalb robust und wartungsfreundlich sein.

Vielleicht ist eine weltweite Verbreitung vorstellbar. An Internationalisierung sollte frühzeitig gedacht werden. Die Unterstützung (translatewiki:) ist zurzeit aber noch dünn. Gleichwohl macht es sich einfacher, wenn von vornherein alle für Benutzer sichtbaren Texte und für das Projekt spezifische Informationen separiert werden.

CSS

Die überwiegende Menge der Gadgets wird nur eine JavaScript-Quelle sein. Sie können aber auch mit CSS kombiniert werden, und ein nur aus CSS-Deklarationen bestehendes Gadget ist auch möglich.

Ausblick und weltweite Gadgets

2011/2012 war geplant gewesen, einen eigenen Namensraum nur für Gadgets in der Software einzurichten, statt sie wie bisher im MediaWiki-Namensraum ablegen zu müssen. Damit sollten auch spezielle Benutzerrechte einhergehen, mit denen auch Benutzer editieren können, die keine Administratoren sind. Dies ist Mitte 2015 zumindest technisch eingerichtet worden.

Weiterhin gibt es Pläne, ein weltweites Depot für Gadgets anzulegen, die in vielen Projekten einsetzbar sind, und diese vereinfacht und aktualisiert einzubinden.

Seit Mitte 2012 scheinen die Bestrebungen eingeschlafen zu sein.

mw:ResourceLoader/Version 2 Design Specification (englisch)
mw:ResourceLoader/Migration guide (users) #Keep gadgets central – weltweite Gadgets (englisch)

Wartung und Pflege; Verantwortung und Lebensdauer

Man muss davon ausgehen, dass ein Gadget nach zwei bis drei Jahren „veraltet“ ist. Das muss nicht sofort bedeuten, dass es nicht mehr funktioniert; es passt aber nicht mehr zu veränderten Rahmenbedingungen im Projekt, und bestimmte Syntaxkonstruktionen wirken antiquiert. Nach und nach machen sich immer mehr Unzulänglichkeiten, fehlende Kompatibilität und Konflikte bemerkbar.

Nach rund fünf Jahren ohne Weiterentwicklung wird auch die Funktionalität bis zur Unbrauchbarkeit eingeschränkt.

Folgerungen:

Skripte funktionieren am besten, solange die Entwickler noch aktiv sind.
Man muss damit rechnen, etwa jährlich ein wenig nachzuarbeiten.
Je komplexer Aufgabe und Lösung sind, desto kürzer die Lebensdauer.
Ein kleines Helferlein mit einem Dutzend Zeilen wird stabiler sein; auch wenn es nach einigen Jahren durch drei Statements ersetzt werden kann, weil inzwischen Bibliotheksfunktionen verfügbar wurden.
Die Wartung durch Nachfolger ist schwierig.
Gute innere Dokumentation des Quellcodes ist erforderlich; schon damit ein Autor es nach einem Jahr selbst noch nachvollziehen kann, was hätte passieren sollen – umso mehr ein späterer Maintainer.
Veränderliche Bedingungen (Internationalisierung, Zeichenketten, Codes, URL und Seitennamen) sollten nicht mitten im Quellcode direkt genutzt werden, sondern von vornherein in Konfigurationsblöcken im Kopfbereich des Quellcodes gesammelt werden.

Wenn man sich ansieht, was sich 2011 und seit 2008 geändert hat, wird klar, dass oft eine Neuprogrammierung kleinerer Aufgaben statt Weiterführung älterer Quellcodes angebracht ist:

Erst protokoll-relative Links, dann https, wikibits veraltet, jQuery eingeführt, asynchron ladende Browser, addOnloadHook usw. problematisch und schließlich abgeschafft, mw-Objekt mit Modulen für Standardaufgaben verfügbar. Zukünftig keine globalen Variablen mehr.
Nur monobook, kaum Nutzung von Quellcode auf anderen Seiten.