Benutzer Diskussion:Perhelion/signing

Eröffnung des Feedbacks

Ich eröffne dann mal die Kommentare:

• Wikipedia:Technik/Skin/Werkstatt magst du auch in die RE-Liste aufnehmen? Vielleicht jede erkstatt (Kartenwerkstatt). Dann gibt es bei Admins noch allerlei mit Anfragen, SP, usw.
• Ansonsten sieht man, dass du bei der Überarbeitung des Olliminatore die Hinweise auf WP:JS betreffend veralteter Praktiken beherzigt hast. Hattu feinemacht.
• Vor Jahren wurden Funktionen offen definiert. Dies hat dazu geführt, dass mittlerweile Hunderte von Funktionen und globalen Variablen beim Benutzer herumschwirren und es zu Namenskonflikten, mindestens aber zu unübersichtlichem Debugging kommt.
  • Als Chrome-Benutzer würdest du die Erweiterung Firebug Lite benötigen, falls du diese nicht schon längst hast. Dann DOM → mw → libs, und schon unterwegs siehst du, was ich meine.
  • Bereits Olliminatore hatte bei addOnloadHook eine anonyme Funktion verwendet, die das Problem der Namenskonflikte soweit vermeidet. doSign() ist also nach außen unsichtbar.
  • Mittlerweile wird pro Werkzeug nur noch ein Anwendungsobjekt gewünscht, das auch unter mw.libs abgelegt werden kann. Alle zugehörigen Funktionen und Variablen sind danach Komponenten dieses Anwendungsobjekts. Dann weiß man bei jeder Funktion sofort, wo sie hingehört.
  • Das momentane Skript produziert drei Funktionen addEvent, removeEvent, getCaretPos und u.a. eine Variable window.editform – die Gefahr laufen, dass ein anderer Programmierer unter gleichem Namen etwas anderes vereinbart.
  • Eine Lösung wäre es, zu definieren

 if ( typeof( mw.libs.threadSign )  !==  "object" ) {
    mw.libs.threadSign  =  { };
 }

und anschließend beispielsweise

 mw.libs.threadSign.editform =
 mw.libs.threadSign.init =
 mw.libs.threadSign.ready =
 mw.libs.threadSign.addEvent = function (obj,type,fn) {
    if(obj.addEventListener) ...
 }

Deine Benutzer hätten dann die Möglichkeit, in ihrer common.js alternativ zu definieren:

 mw.libs.threadSign  =  { config: { weitereRegexp: [...],
                                    usersignature: "...",
                                    sigAccessKey:  "."
                                   } };

Vergleiche hierzu: WSTM.object

• Was genau ich mit dem Array benutzerdefinierter regexp machen soll, habe ich nicht ganz verstanden. Es scheint, dass sie wie wohl auch bei Olliminatore komplett ersetzt werden?
  • Mit arr1.concat(arr2) könnten zwei Arrays verbunden werden, also wenige zusätzliche benutzerdefinierte an die lange Standard-Liste anzugehängen wären – wenn die regpages auf jeden Namensraum angewendet werden sollen.
• In praktisch jedem WMF-Wiki hat der Projekt-Namensraum die Nummer 4. Weil alle momentanen regpages wohl damit zu tun haben, kannst du all diese ünsche, andidaten und erkstatt auf diesen WP-NR=4 beschränken. Das spart Zeit und Missverständnisse bei kuriosen Seiten-Namen. Die Benutzerdefinierten mögen mit Portalen und Redaktionen zu tun haben und könnten auch in allen geradzahligen NR>0 greifen; wenn Unsinn passiert, sind die doofen Benutzer schuld.
  • Im ANR (und theoretisch, aber nicht praktisch: Spezial=-1) sollte überhaupt nie was passieren, richtig? Nebenbei: Spezial=-1 ist ungerade (%1), kann aber nie signiert, kann ohnehin nicht editiert werden.
• Weil du nowiki gesetzt hast, brauchst du wohl keinen \ in ~~\~~ zur Verhinderung.
• signing_init() funktioniert, aber wie wäre es mit der oben beschriebenen Technik und: mw.libs.threadSign.init(regpages, usersignature, sigAccessKey)
• Statt getCaretPos() von Olliminatore gibt es inzwischen für aktuelle Browser gepflegtes und wesentlich eleganteres jQuery.textSelection() – aber nicht ganz trivial einzusetzen. Sage ich dir gern gelegentlich, wie das geht; müsste aber erstmal begreifen, was bei dir/Olli eigentlich alles passieren soll.
• Ich habe in der Schublade ein universelleres beforeSaveHook, das zur Registrierung beliebiger Funktionen gedacht ist, die ausgeführt werden sollen, bevor man eine Seite speichert, oder die beabsichtigte Abspeicherung wieder abbrechen. removeEvent(editform.wpSave,"click",doSign); wäre damit zu ersetzen. Das wird aber irgendwann in 2012.
• Betrifft Benutzer:Perhelion/signing: Zwischen é und ' in ':Café' stehen zwei unsichtbare LTR.

Genug kommentiert, rundherum gelungen; Guten Rutsch --PerfektesChaos 21:16, 29. Dez. 2011 (CET)

Vielen Dank, super Feedback, mehr als ich je erwartet hätte!! Vorlage:Smiley/Wartung/:d  An der eigentlichen Mechanik des UrsprungsSkripts habe ich ja nichts geändert. Ich habe nur – grob gesagt – die Kompatibilität und 3 kleine Features erweitert. Das wird noch ein wenig Arbeit werden, alle deine Hinweise umzusetzen, dieses Jahr werde ich wohl nicht mehr dazu kommen alles umzuschreiben, Vorlage:Smiley/Wartung/hammer  geschweige denn erstmal detailliert zu antworten.Vorlage:Smiley/Wartung/:o  Um weiteres Belesen werde ich nicht rumkommen, hört sich alles super an, ich denke die beiden Event-Funktionen können ebenso durch jQuery ersetzt werden. Also packe ich demnächst alles in threadSign, ich werde nicht drumrum kommen dich auch namentlich im Header zu erwähnen, da ich wohl nochmal hier und da auf dich zurückkommen werde. Vorlage:Smiley/Wartung/:p  Ich sehe nun es ist noch viel Platz für Optimierung und Testläufe. Guten Rutsch bis dann! -- πϵρήλιο ℗ 22:03, 29. Dez. 2011 (CET)

Na, dann bekommst du im zweiten Durchgang noch ein paar hinterher, für 2012:

• getCaretPos()

  Zusätzlich einfügen, unmittelbar nach txtarea = editform.elements['wpTextbox1'];

         mw.libs.threadSign.$txtarea = jQuery("#wpTextbox1");

Später, an Stelle der Zeile

         pos = getCaretPos(txtarea);

die Zuweisung

         pos = mw.libs.threadSign.$txtarea.textSelection("getCaretPosition");

und die gesamte Definition von getCaretPos() erstmal auskommentieren, wenn es funktioniert, kann sie raus.

Das threadSign.$txtarea lässt sich beim weiteren Umbau noch für andere Sachen benutzen.

• wikEd

  wikEdUseWikEd kommt mehrfach vor; ist auf einem Stand vor September 2010.

  Statt der Zeile

   if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) WikEdUpdateTextarea();

zunächst die längere, aber narrensichere und dabei schnelle Konstruktion

   mw.libs.threadSign.wikEd = window.wikEd;
   if (mw.libs.threadSign.wikEd) {
      mw.libs.threadSign.wikEd = (typeof window.wikEd === "object");
      if (mw.libs.threadSign.wikEd) {
         if (window.wikEd.useWikEd) {
            window.wikEd.UpdateTextarea()();
         }
      }
   }

Später gibt es

  if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) WikEdUpdateFrame();

Dafür nehmen wir jetzt

  if (mw.libs.threadSign.wikEd) {
     if (window.wikEd.useWikEd) {
        window.wikEd.UpdateFrame();
     }
  }

Merke: Auch wikEd hat seine Einzel-Variablen und -Funktionen umgestellt auf wikEd. als Anwendungs-Objekt.

• Die Gesamtstruktur habe ich noch nicht verstanden.
  • Eingebettet ist sie in ein Konstrukt

    (function($){ ... })(jQuery);

Das kann man machen, wäre aber eher üblich für eine Erweiterung, die man dann als jQuery.signing() starten möchte. Grundsätzlich geht sowas, scheint mir hier aber thematisch nicht beabsichtigt; könnte sein, dass du gemeint hast, ganz am Ende anzugeben:

         $(signing_init);

oder gleichbedeutend und verständlicher

         jQuery(document).ready(signing_init);

Was in diesem Zusammenhang gemeint ist mit Für eine Einbindung in PDD's Monobook ist eine kleine Anpassung notwendig (da unter anderem ab Version 1.61 das Skript extern gestartet wird). kann ich nicht überblicken.

• Allgemein kannst du die Initialisierungsphase zweistufig anlegen:
  1. Alles, was du schon am Anfang weißt, nämlich welcher Namensraum, und ob überhaupt irgendwas passieren soll.
     • Wenn kein Disku-Namensraum und auch kein geeigneter Seitentitel, dann kannst du sofort komplett aussteigen und musst den Benutzer keine Zeit kosten und nix weiter machen. Dazu muss das document noch nicht ready geladen sein.
     • Übrigens fällt mir auf, dass das alles nur sinnvoll ist, wenn wgAction==="edit" oder "submit". Das kann von vornherein geprüft werden; wenn nicht, dann brauchst du weder zu warten noch nach einem editform zu suchen noch mit Events zu hantieren.
  2. Wenn du in der ersten Phase entschieden hast, dass das Skript wirklich aktiv werden soll, wäre jQuery(document).ready() abzuwarten und die dortige Funktion der zweiten Stufe fasst alles an, was vom ferig geladenen Dokument benötigt wird, also editform und die Knöpfe und Events usw.

Das sollte jetzt bis 2012 reichen; Guten Rutsch --PerfektesChaos 10:07, 30. Dez. 2011 (CET)

Hallo PerfektesChaos, vielen Dank für die weiteren Hinweise. Ich habe nun alles nach langen langem Lesen und Testen und Kopieren, mehr oder weniger, so wie du es vorgeschlagen hast hinbekommen. Ich hatte mit einigen Problemen der Lade-Reihenfolge zu kämpfen. Das Einbettungs-Konstrukt habe ich von Schnark abgeschaut, ja ich dachte mir es ist sowas wie (document).ready, was er in fast allen seinen Scripten so benutzt. Ein anderes Problem war dass die funktionen als Object Variablen nicht als Funktionen akzeptiert wurden, s [1]. -- πϵρήλιο ℗ 20:16, 4. Jan. 2012 (CET)

Aha, ich sehe es mit Wohlwollen. Getestet habe ich nichts, aber beim Drüberlesen fiel mir noch etwas auf:

• if ((typeof wikEdUseWikEd != 'undefined') && wikEdUseWikEd) UpdateTextarea();
  • Das wäre zum einen überaltert, weil wir wikEdUseWikEd als veraltet rauswerfen. Zurzeit schlägt es trotzdem noch an, aber mit dem Fehler: Unbekannte Funktion "UpdateTextarea". Weil: window.wikEd.UpdateTextarea()
• Den scope von editform, txtarea, txtOld, txtOldEnd, $tmpNode durchschaue ich grad nicht; wohler wäre es mir mit var.
  • Zu überlegen ist, ob dies nur innerhalb der Funktion doSign vorkommt oder Komponente von libs.threadSign sein soll.
  • Zu jeder einzelnen Variablen (oder Funktion, was aufs Gleiche hinausläuft) sollte man sich überlegen, in welchem scope sie benötigt wird, und diesen immer so klein wie möglich zu halten.
  • Auf MediaWiki gibt es Anwandlungen, JS so zu schreiben, dass Funktionen/Variablen „privat“ und damit völlig unsichtbar und vom Benutzer auch nicht aufrufbar sind. Das kann man machen, wenn man eine weltweite Basis-Software schreibt und Benutzer in der ganzen Welt da draußen daran hindern will, dass sie interne Funktionen benutzen, die man nicht dauerhaft im Sinne einer API unterstützen mag, und die man ohne Vorwarnung verändern möchte. Allerdings hindert man sich dadurch als Entwickler auch selbst am schnellen, einfachen und jederzeitigen Debuggen. Solange dies als Komponente von mw.libs.threadSign aber nicht im globalen Namensraum herumsteht, ist das in deinem Fall weniger dramatisch. Wer auf eigenes Risiko interne Funktionen oder Variablen aufruft, die nicht in der Beschreibung als benutzerverwendbar ausgewiesen sind, handelt auf eigenes Risiko und kann sich nicht beschweren, wenn sich später etwas ändert.

Viel Spaß weiterhin damit --PerfektesChaos 09:48, 5. Jan. 2012 (CET)

Danke nochmals, tatsächlich fehlte da was (war mir eigentlich sicher alle WikE-Aufrufe ersetzt zu haben) bzw. war zuviel. Nun habe ich alle 3 Helfer-Funktionen durch jQuery ausgelagert und die wunderbare API query Funktion eingefügt (natürlich sollte diese Ressourcen schonend eingesetzt werden, vielleicht sollte diese standardmäßig deaktiviert). Ich habe einiges gelernt und verstehe das Skript nun ganz. Ich glaube die Funktion doSign könnte gleich ans Formular onsubmit übergeben werden und nicht an alle Buttons einzeln. Wenn es jemand als Gadget vorschlagen würde, müsste ich wohl die Option für die eigene Signatur entfernen!? Ich warte immer noch auf Benutzer-Bug-Meldungen, selber werde ich es nicht tun. PS. Habe jetzt ein weiteres ähnliches Skript neu erstellt bzw. adaptiert: sectionSummary.js Lieben Gruß -- πϵρήλιο ℗ 22:45, 7. Jan. 2012 (CET)

Vor einem Vorschlag als Gadget würde ich empfehlen, es als Benutzerskript noch weiter reifen zu lassen. Auf anderen Browsern, mit anderen Skins ergibt sich im Lauf der Zeit oft noch etwas von den ersten Benutzern im Real-Einsatz. Viel Spaß damit --PerfektesChaos 10:32, 8. Jan. 2012 (CET)

Bei Vorschau nicht unterschreiben

Ist es denn Absicht, dass die Signatur schon eingefügt wird, wenn man nur die Vorschau aktiviert?

Ich sehe mir, wenn ich einen längeren Beitrag schreibe, durchaus öfters die Vorschau an und setze (oder vergesse ;) ) die Signatur nur ganz am Schluss. Ich persönlich würde es deshalb vorziehen, wenn das Skript nur beim Speichern aktiv wird.

Lässt sich das einbauen oder ist das explizit unerwünscht? --Patrick87 (Diskussion) 06:57, 19. Mai 2013 (CEST)

Hallo Patrick, erstmal freut es mich dass Du das Script verwendest und auch noch Feedback gibst. Ja das ist beabsichtigt, da es leider keine 100%ige Garantie gibt dass eine Signatur-Platzierung gefunden wird. Leider hängt daran ein weiterer Bug des Scripts, die Warnfunktion funktioniert nämlich nicht. Daher muss ich wohl auch hier in der Werkstatt nachfragen. (Ansonsten könnte man deinen Wunsch über einen Parameter sicherlich bewerkstelligen.) -- ΠЄΡΉΛΙΟ 11:32, 12. Jun. 2013 (CEST)

Vorhandene Signatur in unbenannten nummerierten Vorlagenparametern nicht erkannt.

Wenn man die Signatur in einer Vorlage als unbenannten nummerierten Parameter benutzt, etwa {{Erledigt|1=~~~~}}, dann wird die Signatur nicht als solche erkannt und eine zusätzliche Signatur eingefügt (was natürlich meist nicht erwünscht ist). Bei benannten Parametern, sowie unbenannten Parametern ohne explizite Angabe der Parameternummer wird die Signatur übrigens problemlos erkannt.

Lässt sich das beheben? --Patrick87 (Diskussion) 22:27, 11. Jun. 2013 (CEST)

Hallo Patrick, ja schon. Diese Änderung hatte ich erst vor kurzem eingefügt. Da aus mir unbekannten Gründen die Signatur nicht gesetzt wird in der Grafikwerkstatt. durch dieses {{Erledigt|1=~~~~}} in einem Kommentar (welcher eigentlich alle Signaturen ignorieren lässt). Also ein Regexp-Problem. Da müsste ich in der Werkstatt nachfragen. Ich nehme meine Änderung erstmal wieder raus. PS.: tatsächlich habe ich deinen vorherigen obigen Beitrag übersehen. -- ΠЄΡΉΛΙΟ 11:26, 12. Jun. 2013 (CEST)

Ah, ich sehe das Problem. Das es in der Grafikwerkstatt nicht funktionierte, war mir selbst schon aufgefallen. Allerdings bin ich auch recht schnell drauf gekommen, dass es an der Signatur im HTML-Kommentar liegen muss, was in meinen Augen keinen Fehler im Skript darstellt (solche Spezialfälle trotzdem unterstützen zu wollen ist natürlich lobenswert!).

Ohne von JavaScript allzu viel Ahnung zu haben oder mich mit dem aktuellen Code des Skripts auszukennen: Sollte es nicht einfach sein HTML-Kommentare und Text zwischen <nowiki> Tags schlicht zu ingorieren? Mit einem einfachen RegEx müsste man die betreffenden Textabschnitte doch einfach löschen können? --Patrick87 (Diskussion) 11:45, 12. Jun. 2013 (CEST)

Ja genau, das Problem sollte Dank der Hilfe der JS-Werkstatt nun gelöst sein (so einfach war die Angelegenheit nicht, s. dort).Vorlage:Smiley/Wartung/:)  -- ΠЄΡΉΛΙΟ 10:49, 13. Jun. 2013 (CEST)