Benutzer Diskussion:PerfektesChaos/js/preferencesGadgetOptions

Zur ersten Version

Ursprünglicher Abschnittstitel: "Frühzeitig in der Ausführung des Gadgets informiert der folgende Code den ResourceLoader, wo der Quellcode der hier beschriebenen Skriptbibliothek zu finden ist. Das ist preiswert und erfordert keine Aktivität im Netzwerk." [PC]

• Sobald der umseitige implement-Code-Schnipsel ausgeführt wird, lädt er auch schon das Script. Kann man sehr schön im Netzwerk-Monitor nachvollziehen.
  • Das ist aber gar kein Problem, da Administrator einfach ein utility-gadget-modul daraus machen kann, indem er es auf MediaWiki:Gadgets-definition registriert.
    • Dazu müsste man den Code aber kopieren.
• Ich würde es begrüßen, wenn CSS ausgelagert oder wenigstens konfigurierbar wäre. Auch würde ich das Hinzufügen von Klassennamen zu den verschiedenen Elementtypen begrüßen.
• Großartige Arbeit. Ich werde es wahrscheinlich auf Commons installieren. Danach haben schon mehrere Benutzer gefragt.
• Generell würde ich Beispielcodeschnipsel bei Deinen Scripts begrüßen, in denen schnell und einfach gezeigt wird, was den Benutzer erwartet und die man nur per Copy&Paste in die JS-Konsole einfügen muss:

// On [[Special:Gadgets]] run
if (!mw.loader.getState("ext.gadget.preferencesGadgetOptions")) {
	mw.loader.implement("ext.gadget.preferencesGadgetOptions", ["//en.wikipedia.org/w/index.php?title=" + "User:PerfektesChaos/js/" +
		"preferencesGadgetOptions/r.js" + "&action=raw&ctype=text/javascript" + "&maxage=604800&smaxage=10000&*"
	], {}, {});
}
mw.loader.using('ext.gadget.preferencesGadgetOptions', function () {
	mw.libs.preferencesGadgetOptions.form({
		script: "scriptID",
		show: "just a name to show",
		support: "Just a URL",
		suffix: "suffix text",
		fiat: function () {
			console.log(arguments)
		},
		filled: function () {
			console.log(arguments)
		},
		opts: [{
			signature: "justAnOptSig",
			type: "checkbox",
			show: "show option",
			val: true
		}]
	});
});

-- RE rillke fragen? 11:14, 5. Okt. 2013 (CEST)

1. mw.loader.implement läuft sofort los.
   • Stimmt.
   • Hätte mir die von mir selbst geschriebene Doku mal wieder durchlesen sollen: „die Skript-Quellen werden von den angegebenen URL abgerufen, indem“ … ja; aber gegenüber dem unbedingten mw.loader.load() habe ich sofort eine Modul-ID und kann doppeltes Laden über das .loader.getState() vermeiden, und alle weiteren Gadgets können .loader.using() nutzen. Das war der Trick; irgendwas hatte ich mir dabei gedacht. Ginge auch mit einem zweiten Funktionsaufruf konventionell, erscheint mir so aber robuster, weil auch die Zwischenzustände gesetzt werden.
   • An .loader.register() kommt man als Normaldepp ja leider nicht ran; das war, was ich perspektivisch anpeilte und mir im Hinterkopf herumgeisterte. Der sagenumwobene RL2/RL3 soll das ja mal können.
   • Es ist aber kein Schaden, da das Gadget ohnehin zur Durchführung seiner Hauptaufgabe etwa das .fetch() benötigt. Geladen werden muss deshalb sowieso, es geht nur um das Vermeiden gleichzeitigen Mehrfachladens bei asynchronen Browsern durch unterschiedliche Gadgets.
   • Die Dokus habe ich soeben berichtigt und präzisiert.
2. Das Teil muss sich in jedem Projekt für die nutzenden Gadgets analog verhalten; egal ob unter MediaWiki:Gadgets-definition registriert oder nicht. Es darf auch keine Rolle spielen, in welcher Reihenfolge die Gadgets zum Zuge kommen.
   • Eine alphabetische Sortierung nach Gadget-ID habe ich noch auf ToDo; im Moment ist es FIFO.
   • Die Design-Vorstellungen des einen Gadgets dürfen weder die Zusammenstellung noch das Design anderer Gadgets beeinflussen; und erst recht nicht die zufällige Reihenfolge der Wirksamkeit.
   • Eine Stil-Vorgabe mag durch ein Projekt für die Zusammenstellung und den Basis-Stil aller Gadgets gesetzt werden; gibt es keine, dann ist es mein Standard.
3. CSS ausgelagert oder wenigstens konfigurierbar
   • Das würde jedem Gadget-Programmierer aufbürden, eine zweite Monster-URL angeben zu müssen.
     • Oder es bringt Ruckelei bei nachträglichem .util.addCSS() (wenn von mir intern ausgeführt).
     • Ein Gadget, in dem eine Anweisung einmal drinsteht, schießt sie auch über Jahre hin ab; in vielen Kopien, auf vielen Wiki-Projekten. Wer später mal der Bearbeiter ist und wer auf welchen Projekten für welches Gadget welche Kopie verändern könnte, liegt für mich außer Reichweite. Deshalb möchte ich die Zusicherungen begrenzen auf JSkript-URL und Modul-ID.
     • Ich bin sowieso knurrig, dass man die dritten und vierten Parameter (style, msgs) mit leeren Klammern angeben muss und kein null/weglassen möglich ist. Ist aber eigentlich nicht für Benutzerskripte vorgesehen, gleichwohl public.
   • Es ist mir aber nicht klar, wer dann CSS konfigurieren sollte:

     1. momentaner Benutzer
     2. momentanes Projekt, dem die Special:Gadgets gehört?
     3. Ein Gadget?
        • Das darf keine Zusammenstellung umgestalten; höchstens sein eigenes Formular.
        • Hier hatte ich mir im Vorfeld überlegt, eigene Knöpfe für $submit/$close im Formular-Objekt zuzulassen; dann jedoch entschieden, dass es für die Benutzer verwirrender wäre, wenn jedes Gadget für den gleichen Zweck anders beschriftete Knöpfe hätte, und mehrere Formulare gleichzeitig offen sind.
        • Jedes Gadget bekommt sowieso das jQuery-Objekt seines eigenen Formulars zurück und kann es in eigener Verantwortung umdekorieren.

   • Ich kann gern auf Projektebene vorab definierte Buttons berücksichtigen, die meine in schlichter kulturunabhängiger internationalisierter Bilderschrift durch peppigere ersetzen.
   • Ich kann weiterhin auf Projektebene bestimmte explizite CSS-Definitionen akzeptieren, die die von mir erstmal verwendeten expliziten CSS-Definitionen ersetzen; bzw. eher einen fertig dekorierten jQuery-Wrapper samt Überschrift für den Abschnitt zu den benutzerdefinierten Gadgets.
   • Eine solche Projektkonfiguration würde nur in einer Initialisierung wirksam sein, bevor das erste Gadget sich registriert.
4. Klassennamen zu den verschiedenen Elementtypen
   • Was konkret schwebt dir dabei vor?
   • Jedes singuläre Element hat bereits eine ID; bliebe noch eine Formularklasse oder sowas?
   • Zu CSS ansonsten wie vorstehend.
5. Ich werde es wahrscheinlich auf Commons installieren.
   • Das kannst du ja gerne tun.
   • Ich habe nur den Zweck nicht verstanden, noch die Bedingungen, unter denen es dann geladen wird.
   • Sobald ein Benutzer ein Gadget für sich aktiviert hat, in dem von diesen Möglichkeiten Gebrauch gemacht wird, holt es sich sowieso die Bibliothek.
   • Ist für den Zweck der Wiki-Seite kein Gadget aktiv, wird die Bibliothek auch nicht geladen.
   • Es gibt beliebig viele Gadgets für beliebig viele Aufgaben; teils projektunabhängig. Wenn eines aktiv wird und meint, die Bibliothek zu brauchen, und sie wurde noch nicht bereitgestellt, dann holt es sie am angegebenen Ort ab.
   • Deshalb würde MediaWiki:Gadgets-definition auch nicht weiterbringen; genausowenig MediaWiki:Common.js usw. Weder kann ein Benutzer ein Opt-In oder Opt-Out machen, noch wäre ein zwangsweises Laden in Common.js sinnvoll, weil die Gadgets über die Notwendigkeit autonom entscheiden. Wenn die Bibliothek nicht gebraucht wird, passiert nix. Ich belästige doch nicht wie ULS/IME/VE unterschiedslos alle Benutzer bei jedem Seitenaufbau.
6. Großartige Arbeit.
   • Danke, sowas liest man gerne.
7. Beispielcodeschnipsel
   • Gern, in Richtung einer ganzen Versionsnummer, samt Screenshots.
   • Erstmal habe ich einen Anfang gesetzt; heute Abend kam das erste serienmäßige Gadget von mir auf den Server, in den kommenden Wochen drei weitere.
   • Die Geschichte hat die Versionsnummer 0.1 und steht so zwischen Alpha und Beta; jetzt müssen erstmal Außenstehende damit arbeiten und Wünsche äußern. Du bist der erste.
8. Rückfrage:
   • Du hattest heute am späten Vormittag auf der enWP die Doku und das r.js „überprüft“ – so meldete das Echo.
   • Was genau versteht man hier unter „überprüft“?

Schönen Sonntag --PerfektesChaos 20:35, 5. Okt. 2013 (CEST)

Zur letzten Frage: Ich wusste gar nicht, dass das ein Echo verursacht. en:Wikipedia:New pages patrol/patrolled pages erklärt dieses Feature: Ich habe damit bestätigt, dass es sich um eine Seite der Kategorie Any page that is appropriate for Wikipedia handelt. Inzwischen drücke ich reflexartig auf diesen Patrol-Link, wenn ich feststelle, dass es sich weder um Vandalismus noch um Werbung handelt. Diese fallen dann aus den Unpatrolled Edits heraus und Leute, die Vandalen jagen, haben weniger nachzugucken. Das ist also kein Code-Review.-- RE rillke fragen? 23:03, 5. Okt. 2013 (CEST)

Ah, mangels Artikelarbeit in der enWP habe ich keine Sichterrechte oder wie das heißen mag und sehe auch keinerlei Knöpfe. 4 unbestätigte Seiten – vor allem verblüfft mich, dass das mit Benutzerseiten passiert. Als Artikel okay, vielleicht auch noch Projektseiten mit Hilfe und Vorlagen; aber Benutzerseiten? Na ja, werde mir mal eine Fehlerliste greifen und in Mußestunden automatisiert Syntax fixen müssen. Danke für die Aufklärung --PerfektesChaos 00:08, 7. Okt. 2013 (CEST)

Klassenkampf

Klasse gibt es jetzt eine. Aber dafür 5 jQuery-Objekte zur projektweiten Vorgabe. Da lassen sich sogar Einleitungssätze und Links auf erläuternde Seiten unterbringen; also mehr als eine simple Klasse.

Näheres siehe neuer Abschnitt.

Alternativ und vorrangig zu Definitionen über die JS-Komponente .config könnten statische HTML-Quellcodes fälschungssicher im Mediawiki abgelegt werden. Bloß käme ein JS da nicht ran und müsste es erst über API abfragen, was den Aufbau der Spezialseite unzumutbar verzögert. Die Hinterlegung im Messages-Objekt hingegen kann genauso überschrieben werden wie mein eigenes Anwendungsobjekt. Ich kann allerdings beim ersten zufällig auftauchenden Gadget/Laden den Bestand privatisieren und mache dies auch.

Bis dann --PerfektesChaos 00:08, 7. Okt. 2013 (CEST)