Wikipedia:Lua/Werkstatt/Archiv/2019

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Direkteinbindung in Artikeln?

Siehe auch diese Anfrage aus dem Mai 2017. Ich halte das nicht für sinnvoll, weiß auch nicht wie man so etwas dann angemessen mit einer TemplateData-Dokumentation versehen soll.

Vorlage
Erzeugt von: #invoke:Sports table
Bearbeiten

Insgesamt scheinen diese 9 Artikel betroffen zu sein

Die Angabe Erzeugt von: #invoke:Sports table finde ich sehr verwirrend. Wer weiß schon als Laie was ein #invoke sein soll.

Was tun? --Liebe Grüße,  Diskussion 08:32, 13. Mai 2019 (CEST)

Diese Werkstatt hier ist unzuständig, weil es nicht um eine Programmierungsaufgabe in der Sprache Lua geht, auch nicht um eine organisatorische Frage im Modul-Namensraum.
Du müsstest dich in erster Linie an den verantwortlichen Autor wenden.
Zuständig ist außerdem das Sport-Portal im Allgemeinen sowie dessen Basketball-Untergliederung.
Es ist nicht dein Problem „wie man so etwas dann angemessen mit einer TemplateData-Dokumentation versehen soll“ – da müssen sich die Fachautoren und die Fachprojekte einen Kopp machen.
Das ganze Manöver sieht mir sehr nach C&P aus der enWP aus, ohne dasss ich Zeit und Nerven hätte das genauer zu erforschen.
Es bekommt niemand auch nur einen Handgriff an Support, wenn sein Zeugs eines Tages crasht und die Artikel kaputt sind, falls nicht von Vornherein alle Spielregeln eingehalten werden und ordnungsgemäß dokumentiert und strukturiert wird.
Wenn die Basketballer das ihrem Modulkopierenden und mutmaßlich Artikel aus der enWP kopierenden Selten-Benutzer so durchgehen lassen, dann können sie sich zukünftig ohne Hilfe dieser Werkstatt oder der VWS ihre Artikel selbst reparieren, falls die erwartungsgemäß irgendwann auf die Fresse fallen.
VG --PerfektesChaos 14:37, 13. Mai 2019 (CEST)
Na ja es ist halt Lua, wo sollte ich denn sonst damit hin? Na ich kopiere es mal an einen anderen Ort. Hoffnung, dass es irgendjemanden interessiert, habe ich da aber eher keine. --Liebe Grüße, Lómelinde Diskussion 15:40, 13. Mai 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Lómelinde 15:40, 13. Mai 2019 (CEST)

Vorlagenaufruf/-einbindung in LUA-Modul

Unter Beachtung der Spielregeln erbitte ich eine kurze und sachliche Antwort auf folg. Aufgabenstellung:

  • Im Lua-Modul soll ein Vorlagenaufruf, z.B. {{VorlageXYZ|ABC|para=123}} zusammengestellt und funktionsfähig an die Vorlage, resp. den Artikel zurückgegeben werden. Ich weiß, das das weder logisch noch auf diesem Weg praktikabel ist, da als Ergebnis im Artikel nur ein Textstring ‚{{VorlageXYZ|ABC|para=123}}‘ erscheint und nicht das Ergebnis der generierten Vorlage.
  • Gibt es überhaupt eine Möglichkeit den Vorlagenaufruf so zu gestalten, dass er abgearbeitet wird? Ja/Nein
  • Kennt jemand einen Link zu einer hilfreichen Antwort/Anleitung, zu einer funktionierenden Anwendung oder kann jemand in ein paar Musterzeilen den Weg aufzeichnen? Wenn Ja, bitte ich darum, wenn Nein, reicht NEIN oder - besser noch - meine Frage einfach ignorieren.
  • Wie man eine Vorlage erstellt, auch mit LUA be-/verarbeiten kann oder auch bestehende Module/Funktionen einbindet, ist mir bekannt und muss mir hier nicht weitläufig beschrieben werden.

Herzlichen Dank --Klaus-Peter 13:31, 22. Okt. 2019 (CEST)

Ganz kurz: Ich glaube, du suchst frame:expandTemplate{ title = title, args = table } oder frame:preprocess(). Mehr dazu unter mw:Extension:Scribunto/Lua reference manual. Gruß—XanonymusX (Diskussion) 13:57, 22. Okt. 2019 (CEST)
Ersatzweie deutsch: Hilfe:Lua/Modul im Wiki #frame:expandTemplate()
Es ist nichts Böses daran, eine normale Vorlage einzubinden, wenn keine Lua-Schnittstelle für eine derartige Aufgabe exisitert.
VG --PerfektesChaos 14:26, 22. Okt. 2019 (CEST)
DANKE für die flotte Antwort. Die englische Version ist -- wie fast immer -- einen Tick besser und brauchbarer. Will mal sehen, ob ich damit zu Potte komme. Schönen Tag noch --Klaus-Peter 15:41, 22. Okt. 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: Beantwortet --Klaus-Peter 15:41, 22. Okt. 2019 (CEST)

Wie geht das im BNR? (Btr. Vorlagen & Module)

Irgendwie lese ich die falschen Anleitungen oder ich verstehe sie nicht.

Es geht um das Schreiben und Testen von Modulen. Angeblich hat hat es auf der Spielwiese Möglichkeiten {{EV|13|pix=60|txt=sonst was}} direkt einzubinden und angeblich wird dann eine Vorlage im Verzeichnisbaum des Benutzers aufgerufen. Das klappt in meinem BNR bzw. auf meiner Spielwiese nicht!

Vorlagen kann ich nur erreichen, wenn ich z.B. {{Benutzer:Gadacz/Spielwiese/Vorlage:EV|13|pix=60|txt=sonst was}}, also mit voller Adresse aufrufe. Aus Benutzer:Gadacz/Spielwiese/Vorlage:EV kann ich mit {{Dokumentation}} problemlos Benutzer:Gadacz/Spielwiese/Vorlage:EV/Doku einbinden. Aber {{#invoke:EV}} bzw. {{#invoke:EV|13|pix=60|txt=sonst was}} führt aus der Vorlage:EV statt zu Benutzer:Gadacz/Spielwiese/Modul:EV ins Nirvana. Dabei habe ich mich auch erfolglos mit zusätzlichen Pfadangaben versucht -- will einfach nicht.

Das LUA-Modul funktioniert als Standalone einwandfrei (Verbesserungen und Optimierungen stehen aus). Nur wenn ich weiterhin daran 'privat' auf meiner Wiese herumbasteln will, um zu einem brauchbaren Ergebnis zu kommen, sollte ich zumindest die Aufrufe und Parameterübergabe irgendwie realisieren können. WER KANN HELFEN? Wer kann meine Fehler finden? Wer hat Tipps oder Links zu funktionierenden Mustern, wo ich 'klauen' kann?

Letztendlich soll {{EV|13}} so etwas ergeben wie EuroVelo13 Iron Curtain Trail (EV13)
--Klaus-Peter 16:19, 24. Aug. 2019 (CEST)

  • In einer fertigen Fassung solltest du nichts verwenden, was irgendwie mit einer unverständlichen bzw. vieldeutigen Abkürzung „EV“ zu tun hat.
  • Am einfachsten geht es, wenn du folgende Seitennamen verwendest:
    • Modul:Benutzer:Gadacz/EuroVelo für Lua
    • Benutzer:Gadacz/EuroVelo als Test-„Vorlage“
  • Dann weißt du immer genau, was wann wo eingebunden ist.
VG --PerfektesChaos 16:35, 24. Aug. 2019 (CEST)
Im Moment habe ich auch bei Spielwiese/EV noch den Überblick. "EV" wird auch sicher nicht an die Öffentlichkeit gehen. Ich habe mich bei dem Problem zuerst mit Vorlagenprogrammierung versucht, das ist aber zu starr und fehleranfällig. Das kann LUA deutlich kürzer und eleganter. Nur die Anleitung, wie WP mit LUA kommuniiziert, scheint ein gut verstecktes Geheimnis zu sein. Da bieten dann Experten wie «PerfektesChaos» mit Modul:Benutzer:Gadacz/EuroVelo einen Aufruf an, der zwar die Datei findet, aber brav den Source auf den Bildschirm bringt, was nur verwirrt und nichts nützt. Immerhin, mit {{#invoke:Benutzer:Gadacz/Spielwiese/EV}} bin ich schon mal deutlich weiter gekommen. Da sehe ich sogar Meldungen wie "Skriptfehler: Das Modul gab einen string-Wert zurück. Es wird angenommen, dass eine Tabelle zum Export zurückgegeben wird". Keine Ahnung, für was ich eine Tabelle brauche. Jetzt muss ich an der Parameterübergabe und Rückgabewert basteln, wobei WP-LUA scheinbar auch eigene Vorstellungen hat, die von den mir bekannten Programmiersprachen abweichen. Ich denke noch altmodisch mit argc, argv, getenv, return ...--Klaus-Peter 18:03, 24. Aug. 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Klaus-Peter 07:19, 24. Okt. 2019 (CEST)

Gemeinsame Modul-Doku

Gibt es einen im LUA-Modul verwendbare Anweisung, die es ermöglicht, eine spezifische Doku einzubinden.

Bei fehlender Doku wird ja Modul:Modulname/Doku vorgeschlagen und auf Klick angelegt. Sollte sich für mehrere Module eine gemeinsame Doku anbieten, ist das so nicht möglich. Allenfalls könnte man in der standardmäßig angelegten Doku nur {{Gemeinsame_Doku}} eintragen und dort dann die gemeinsam geltenden Angaben machen. Geht es auch ohne diesen Umweg? Herzlichen Dank --Klaus-Peter 10:30, 5. Okt. 2019 (CEST)

Das ist soweit falsch.
Modul:Multilingual/table bietet beispielsweise eine direkte Verlinkung mit der spezifischen Lua-Doku zum Untermodul /table an.
Untermodule sind in aller Regel nicht dafür vorgesehen, dass sie von der breiten Masse der Vorlagenprogrammierer direkt angesprochen werden sollen. Sie sollen üblicherweise nur Funktionen des Bassis-Moduls per #invoke aufrufen.
Mehr für interne Wartungszwecke und für die Zwecke der Lua-Programmierung selbst gibt es an Untermodulen gelegentlich auch Schnittstellen zu #invoke, etwa auch zur globalen Versionsverwaltung.
Siehe im Übrigen Wikipedia:Lua/Seitenorganisation und Dokumentation.
Beachte ansonsten, dass der Modul-Namensraum ausschließlich für Lua-Code vorgesehen ist und die einzigen Seiten, die Nicht-Lua-Code enthalten dürfen, die kleinen Schnipsel /Doku sind, die die Verbindung zu der Vielheit der Wikitextseiten herstellen; etwa Test-Fälle, Über-setzungen usw.
VG --PerfektesChaos 11:20, 5. Okt. 2019 (CEST)
Das es falsch ist, ist mir klar. Auch ich kann Chaos produzieren. Ich habe nicht vor, ohne Ihre ausdrückliche Erlaubnis in die von Ihnen beobachten Namensräume einzudringen. Vorerst mal die Modifikation der Fragestellung: Modul:Benutzer:Icke/Schnick/Schnack, sowie Modul:Benutzer:Icke/Schnick/Schnuck sollen beide die gemeinsame, gleichlautende Doku {{Benutzer:Icke/Schnick/SchnickSchnackSchnuck_Doku}} anzeigen. Da brauche ich keine theoretischen Abhandlungen, sondern auf die konkrete Frage eine klare Antwort. Wie man so etwas via Vorlagen realisieren kann, ist mir schon klar. Meine Frage bezog sich darauf, ob man IM LUA-MODUL eine Funktion anwenden kann, die DIREKT auf eine Doku zugreift, die NICHT Modul:Benutzer:Icke/Schnick/Schnack/Doku oder Modul:Benutzer:Icke/Schnick/Schnuck/Doku heißt. Ihren netten und weitläufigen Umschreibungen entnehme ich, dass Sie mein Anliegen nicht befriedigen können. Ein einfaches NEIN hätte gereicht. Trotzdem verbindlichen Dank. --Klaus-Peter 13:23, 5. Okt. 2019 (CEST)
  • Zwei gleichinhaltliche Dokumentationen machen wir nicht.
    • Sowas wäre redundant oder Anzeichen für einen Konstruktionsfehler.
  • Im Fall der Untermodule würden wir das allgemeine Schema beim Hauptmodul erläutern.
  • Der „Modul“-Namensraum heißt deshalb so, weil dort nur Module, also Lua-Code zulässig sind. Die kleinen Schnipsel /Doku ermöglichen eine Verlinkung mit dem Projektnamensraum, wo beliebig viele Wikitext-Seiten angelegt werden können.
VG --PerfektesChaos 13:45, 5. Okt. 2019 (CEST)
Genau das meine ich. Redundanz mag ich auch nicht, zudem einzelne Dokus bei Änderungen schlecht zu Warten sind. Also, wie ich schon vermutete, läuft alles über den Doku-Schnipsel und die Vorlagenschiene ab. Ist auch kein Problem, nur ein winziger Umweg. Danke--Klaus-Peter 16:24, 5. Okt. 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Klaus-Peter 07:20, 24. Okt. 2019 (CEST)

Auswertung 'pcall'

Häufig sehe ich in Anleitungen und Modulen abenteuerliche Konstruktionen wie dieses Beispiel:

local lucky, FileMedia = pcall( require, "Module:FileMedia" )
if type( FileMedia ) == "table" then
    FileMedia = FileMedia.FileMedia()
else
    return "<span class=\"error\">" .. FileMedia .. "</span>"
end

Ist das Absicht?pcall gibt einen Status (hierlucky) zurück, der bei diesem Aufruf nirgends abgefragt/ausgewertet sondern lediglichtype. Liege ich da falsch? Übersehe ich etwas oder haben die Autoren da über das Ziel hinaus geschossen? --Klaus-Peter 08:07, 20. Okt. 2019 (CEST)

  • pcall() ist eine Funktion, die zwei Rückgabewerte hat, von denen der zweite der Nutzinhalt ist.
    • Um an den Nutzinhalt heranzukommen, muss man beide Rückgabewerte belegen lassen, auch wenn man am ersten nicht interessiert ist.
    • Wer möchte, kann außerdem noch lucky auswerten; es ist false, falls ein Fehler auf System-Ebene vorliegt.
  • FileMedia ist eine table dann und nur dann, wenn das Modul ordnungsgemäß gefunden wurde und es auch die erwartete Tabelle enthält.
    • Wäre es keine table, dann wäre die Initialisierung FileMedia.FileMedia() unzulässig.
  • FileMedia ist ein string mit einer Fehlermeldung des Systems, falls die Modulseite unter diesem Namen nicht existiert oder die Programmierung unzulässig wäre.
    • In diesem Fall wird die Fehlermeldung dargestellt.
    • Vorstellbar wären auch noch Situationen, in denen das externe Modul eine einfache Zahl oder false zurückgeben würde; oder sonstwie nicht das erwartete Modul wäre und die Initialisierungsfunktion nicht kennen würde. Derartige fast schon böswilligen Vertauschungen werden hier jedoch aus Performance- und Übersichtlichkeitsgründen nicht analysiert.
Der Subtext im Adjektiv „abenteuerlich“ und der damit transportierte Angriff könnte ein Grund sein, warum niemand mit dir spielen mag.
  • Derartige Wertungen würden allenfalls jemandem zustehen, der die Situation voll überschaut.
  • Du hast erkennbar nicht diesen Durchblick, wie deine Anfrage zeigt.
--PerfektesChaos 15:42, 20. Okt. 2019 (CEST)
@PerfektesChaos Spielen tue ich auf meiner Spielwiese und produziere da mein eigenes Chaos. Die Antwort zielt wieder mal genial an der gestellten Frage (zu pcall) vorbei. Keine Ahnung oder drücke ich mich zu 'abenteuerlich' aus? Nun, die Reklamation eines ‚damit transportierten Angriffs‘ legt die Vermutung nahe, dass Sie dieses Abenteuer geschaffen haben.
Was pcall bewirkt und zurück gibt, ist selbst für mich Undurchblicker kein Geheimnis. Das erfragte ich auch nicht. LUA gibt es sogar in der Nicht-WP-Welt. Auch ohne lucky und pcall kann ich den Status von FileMedia einwandfrei feststellen und ggf. darauf reagieren. Nach meiner kaum überschaubaren Laien-Meinung reicht:
local FileMedia = require("Module:FileMedia")
   if type(FileMedia) == "table" then
    FileMedia = FileMedia.FileMedia()
   else
    return "<span class='error'>" .. FileMedia .. "</span>"
 end
... und das auch nur, wenn ich unsicher sein muss, dass FileMedia sich über Nacht geändert hat oder verschwunden ist. OK, so etwas kann bei WP schon mal passieren, obwohl es (für mich) etwas schwierig ist, ein fehlerhaftes Modul abzuspeichern. Vermutlich gibt es in diesem Fall keine speziellen Modifikationen bei WP-LUA, die hier etwas anderes bewirken, als 'Common'-LUA. Somit ist meine Frage mit deutlich überlegenem und perfekt demonstriertem Durchblick indirekt beantwortet. Herzlichen Dank! --Klaus-Peter 18:23, 20. Okt. 2019 (CEST)
Nein, dein Ansinnen, pcall() wegzulassen, ist genau das Kennzeichen einer schlechten Programmierung.
In diesem Fall stürzt sofort das gesamte Modul und womöglich ohne eine nach außen sichtbare Fehlermeldung ab; und ohne eine Möglichkeit, noch eine spezifische Wartungskategorie oder eine Selbstreparatur und Fallback-Position zu erzeugen.
Erkennbar ist das lediglich noch daran, dass es sich in der Kategorie:Wikipedia:Seite mit Skriptfehlern wiederfindet.
Dort stehen alle Seiten mit nicht aufgefangenem Programmierfehler nach deiner Strategie drin, die von irgendeinem Modul aus irgendwelchen Gründen in den Abgrund gerissen wurden, und zwar alle betroffenen Seiten gemeinsam.
Du kannst die gerne alle durchgehen und Seite für Seite den Programmierfehler herausfinden und beheben. Sie gehen alle auf schlecht geschriebene Module nach deinen Vorstellungen zurück.
Eine gute und robuste Programmierung würde hingegen die Aufgabe zu einem guten Ende bringen, ein brauchbares Resultat hier auch ohne das erwartete externe Modul generieren, und ggf. mit einer spezifischen Wartungskategorie (wie dieser) reagieren. Vielleicht ist das externe Modul für die Aufgabe ja gar nicht zwingend erforderlich; würde nur ein Sahnehäubchen oder eine zusätzliche Datenanalyse liefern.
Ggf. würde man neben einer spezifischen Wartungskategorie eine für normale Leser unsichtbare Fehlermeldung im Artikel unterbringen, die sich nur die Programmierer sichtbar machen würden. Die Fehlermeldung des Systems, sofern sie überhaupt in der Wikisyntax sichtbar wird, erscheint hingegen knallrot und fett auf jeder Seite.
Nun überlege mal, wie toll sich das ausmachen würde, wenn 100.000 Artikel ein Modul verwenden, und jede 20 oder 100 Mal auf jeder Seite knallrot von einem Programmierfehler berichten.
Im von dir angefragten Fall einer Programmbibliothek kann ein Modul, das auf irgendeinem Wiki abläuft, nur darauf hoffen, dass auch auf diesem fremden Wiki die gleichen Programmbibliotheken verfügbar wären wie zu Hause. Und wenn nicht?
Ach ja, dein tolles Programmbeispiel funktioniert selbstverständlich nicht. Wenn das mit direktem require() angeforderte fremde Modul nicht vorhanden ist, dann ist die Ausführung sofort beendet und deine weiteren Zeilen werden niemals erreicht. An das #invoke: wird die Fehlermeldung des Systems zurückgegeben und das war’s. Bzw. es geht bei irgendeinem anderen pcall() weiter, sofern zufällig noch in der Aufrufstruktur vorhanden. Du hattest deinen Code niemals ausprobiert und dir selbst mal demonstriert; „mit deutlich überlegenem und perfekt demonstriertem Durchblick“ kam hier nur eine untaugliche Lachnummer raus.
Du behauptest, du würdest angeblich wissen, was ein pcall() ist. Nun, wenn sich jemand die Mühe macht, einen einzelnen Funktionsaufruf wie require in pcall() zu verpacken, dann kann das nur den Grund haben, dass mit der Auslösung von error() innerhalb dieses Funktionsaufrufs gerechnet wird.
--PerfektesChaos 22:34, 20. Okt. 2019 (CEST)
Archivierung dieses Abschnittes wurde gewünscht von: --Klaus-Peter 07:21, 24. Okt. 2019 (CEST)

Lua-Fehler in Modul:Musikcharts/countries, Zeile 666: attempt to index global 'frame' (a nil value)

Der obige Fehler erscheint derzeit auf zahlreichen Seiten zu Musikcharts, siehe Kategorie:Wikipedia:Seite mit Skriptfehlern. --Segelschulschiff Pyramus (Diskussion) 11:21, 31. Dez. 2019 (CET)

Hab den Fehler wohl beheben können, bitte prüfen und ggf. sichten. Merci, --Segelschulschiff Pyramus (Diskussion) 11:33, 31. Dez. 2019 (CET)
So in etwa war das gemeint, ja, danke für die Korrektur! Wobei der Teil vermutlich bald sowieso ganz rausfällt, Vorlagenaufrufe aus dem Modul möchte ich auf lange Sicht ganz loswerden. Gruß–XanonymusX (Diskussion) 11:53, 31. Dez. 2019 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: --XanonymusX (Diskussion) 00:31, 5. Jan. 2020 (CET)

Lua-Editor

In etlichen Fällen ist der Editor ja recht hilfreich, aber sein "Komfort" ist mitunter störend:

  • Autoident hat mitunter recht eigenwillige Vorstellungen von Einrückungen. Zudem weicht es teilweise deutlich von der Darstellung im 'normalen' Editor (Umschaltung via <>) oder vom ZeroBrane-Editor ab.
  • Autodelimiter ist teilweise eher störend, als hilfreich, insbesondere bei Korrekturen eines bestehenden Textes mit Klammern und Anführungszeichen.
  • 'Suchen' (^F) läuft bei aktiviertem "Lua-Editor" auf 2 Ebenen ab. Nicht immer hilfreich.

Gibt es eine Möglichkeit, diese "Komfortfunktionen" anzupassen oder abzuschalten? --Klaus-Peter 07:12, 24. Okt. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:57, 4. Jun. 2021 (CEST)

Iteration

Als Neuling in Lua habe ich vergeblich nach einer Antwort gesucht auf die Frage, die ich nun hier stelle. Allerdings, wie ich es bisher verstanden habe ist das Design von Lua so dass die von mir gesuchte Möglichkeit nicht angeboten wird. Für diesen Fall schiebe ich gleich die Frage nach, ob dazu eine Diskussion gestartet werden kann, um eine Implementierung/Erweiterung zu beantragen.

Das Problem

Wir haben massenhaft Vorlagen die mit einer variablen Anzahl vieler unbenannter Parameter umgehen müssen. Das wird in einer hässlichen Kette von {{#if:{{{x|}}}| ... (1 ≤ x ≤ ∞) abgehandelt.

Beispielsweise gibt es in den Commons die Vorlage Other um eine Datei anzuzeigen; dann kam Other2 dazu für zwei Dateien, und schließlich Other3. Weil auch das nicht genug war habe ich die Vorlage (mit den erwähnten Abfrageketten) von drei auf momentan bis zu 20 Dateien erweitert; wenn nun mal 21 Dateien anzuzeigen wären, scheitert die Vorlage erneut.

Die gewünschte elegante Lösung

sollte Lua bringen − denn unsere Vorlagensprache kann keine Iterationen. In dem obigen Other-Beispiel wird die Parameterliste an Lua übergeben, dort in einer do-Schleife abgearbeitet wobei bei jedem Schleifendurchlauf mit sowas wie expandTemplate{ title = eine kleine Untervorlage aufgerufen wird, die genau einen Parameter bekommt und ihn verarbeitet; in anderen Fällen wird eben ein Parameterpaar, oder was auch immer, übergeben.

Lua scheint konzipiert dass nur einmal als Abschluss diese Return-Funktion erfolgt. Nach meinem Verständnis sollte es aber auch möglich sein, "zwischendurch" solche iterativen Vorlagenaufrufe irgendwie abzusetzen − ohne structural violation! Das so umständliche Abhandeln von variabel langen Parameterlisten, wie es in vielen Vorlagen notwendig ist, könnte damit drastisch vereinfacht werden. -- sarang♥사랑 10:46, 23. Dez. 2019 (CET)

Ich habe nicht so restlos verstanden, worauf du hinauswillst, aber vollziehe doch einmal nach, wie Vorlage:min mit ihren Eingabeparametern umgeht.
(P.S.: Seit heute nacht akzeptiert Vorlage:Anker ebenfalls unendlich viele Parameter, aber das weiß noch niemand)
LG --PerfektesChaos 11:00, 23. Dez. 2019 (CET)
@사랑 Irgendwie wird aus historischen Gründen immer noch vorzugsweise auf der Ebene der Vorlagenprogrammierung mit dem {{{Klammerzirkus|}}} gedacht. Der direkte Aufruf von LUA ist nicht erwünscht. Dennoch kann man mit LUA eine Menge machen, wenngleich mir auch php oder c++ lieber sind. In der „Vorlage:Meine“ reicht ein Aufruf {{#invoke:Modulname|startfunktion}}. Alle Parameter aus {{Meine|aaa|bbbb|c=dddd|e=ffff}} werdenn quasi ‚durchgeschoben‘ und können einigermaßen komfortabel in LUA abgearbeitet werden. Die 'startfunktion' im Modul ‚Modulname‘ sammelt alles zusammen. --Klaus-Peter 11:23, 23. Dez. 2019 (CET)

Also nochmal, hoffentlich deutlicher: Wenn eine Vorlage mit einer (grossen) variablen Anzahl von (positional) Parametern versorgt wird, muss jeder Parameter einzeln abgefragt werden, ob er mit Wert belegt ist um in diesem Fall das Entsprechende zu tun. Das gibt eine lange Kette von #if:-Abfragen; und wenn 140mal diese Prüfung erfolgt wird und irgendwann 141 Parameter übergeben werden versagt die Vorlage. Weil nur lineare Programmierung möglich ist und Iterationen nicht unterstützt werden. Lua kann das, mit ganz einfachen "do"-Schleifen, kann aber meines Wissens nicht iterativ eine Vorlage aufrufen - nur einmal am Ende.
Ich zeige hier als code-snipped mit der hypothetischen Funktion "transclude" was mir vorschwebt: 

function p.iteration (frame) 
	local args = mw.getCurrentFrame(): getParent().args;
	for name, value in pairs( args ) do 
		transclude mw.getCurrentFrame(): expandTemplate { title = 'Untervorlage', args = { name, value } }
	end
	return ....
end

Oder, mit noch anderen Worten, bei einem #invoke:-Aufruf soll beliebig oft ein Aufruf an eine andere Vorlage abgesetzt werden können. Ich kann zwar innerhalb einer Vorlage an beliebigen Stellen und beliebig oft andere Vorlagen oder Moduln aufrufen, aber innerhalb eines Moduls zwar unbegrenzt andere Moduln, aber nur einmal am Ende eine Vorlage verwenden. Das ist eine starke Einschränkung, für die ich keine Notwendigkeit erkenne, und die elegante Lösungen solcher Probleme verunmöglicht. -- sarang♥사랑 13:02, 23. Dez. 2019 (CET)

Du kannst mit nur einem #invoke: praktisch unbegrenzt viele Parameter übergeben (bis das Zeitlimit oder sowas zuschlägt).
Danach kann das Innere der Programmierung dieses Lua-Moduls mit diesen unbegrenzt vielen Parametern anstellen was immer es will; das liegt dann in der Verantwortung des Modul-Programmierers. Weil es zwei Abschnitte drunter erwähnt wird: Bei den Beispielen in Vorlage:itS etwa werden für eine Handvoll, aber im Prinzip möglichen 100 oder 200 Sprachen die jeweiligen Sprachnamenvorlagen zu luna eingebunden.
Weil es hier irgendwo thematisiert wurde: Es gibt nur ein Dutzend hiesiger Autoren, die gefestigt Lua können, und nur ein oder mal zwei, die die Programmierung fremder Leute reparieren würden; der Rest ist heilfroh, wenn die eigenen Module noch funktionieren. Sobald du also von klassischer Vorlagenprogrammierung (was vielleicht 1000 Autoren so ein bisserl können) zu Lua wechselst, musst du damit rechnen, dass es niemanden mehr gibt, der das hinterher noch warten und pflegen könnte, insbesondere wenn es mangelhaft dokumentiert ist, und man es deshalb aus den Artikeln und sonstigen Seiten rausschneiden muss.
Das von dir soeben dargestellte snippet ist im Übrigen das, was ich in meinem ersten Satz beschrieben hatte. Warum dazu irgendwelche doll vielen {{#if: benötigt würden, verstehe ich nicht; ich erkenne null. Wikisyntax hat aber hinsichtlich des Parsens von Wikitext notwendige Gesetzmäßigkeiten.
VG --PerfektesChaos 13:19, 23. Dez. 2019 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:57, 4. Jun. 2021 (CEST)

Vorlage:Defekter Weblink

@PerfektesChaos: Das Modul zu dieser Vorlage verursacht zurzeit Skriptfehler. So z. B. in:

u.s.w., also nahezu alle Einträge in Kategorie:Wikipedia:Seite mit Skriptfehlern aus dem NR 1. Wäre echt super, wenn du das beheben würdest. Gruß von ÅñŧóñŜûŝî (Ð) 12:37, 23. Dez. 2019 (CET)

Das bin nicht ich, bzw. Modul Defekter Weblink, sondern das ist die Programmierung der Infobox bzw. des dortdrin verwendeten Wikidata-Moduls.
Die Seite wird zur Analyse der URL auf der Diskussionsseite eingebunden, diese hat aber logischerweise keinen eigenen Wikidata-Item, und weil die Programmierung unseres Wikidata-Moduls sowas nicht abfängt, kommt es zu einem durch mich von außen nicht abzufangendem Absturz.
Die MediaWiki-Wikidata-Programmierung ist so gestaltet, dass es zu einem schweren Crash kommt, sobald man mit einer ungültigen Entity-ID angewackelt kommt, und diesen kann ich auch nicht von außen wieder einfangen.
Musst du dich an Infobox und unser hiesiges Wikidata-Modul wenden, falls es dich doll stört; ich habe das inzwischen aufgegeben.
Ach, und nebenbei: Spezial:Diff/195159102 sehe ich als eher unfreundlichen weil sicher nicht mit dem Ersteller abgesprochenen wie auch sinnlosen Akt an. Bald 6000 unserer allgemein durch Autoren zu verwendenden Vorlagen verwenden den Einleitungsabschnitt von TemplateData als den einen und einheitlichen Einleitungsabschnitt zur Funktionsbeschreibung der gesamten Vorlage. Du irritierst die Anwender mehr, wenn du das grundlos irgendwo nach hinten verknackst, wirst es auch nicht bei Tausenden anderer Vorlagen durch zwei verschiedene Funktionsbeschreibungen mit und ohne TemplateData ummodeln, und hilfst niemandem.
VG --PerfektesChaos 12:49, 23. Dez. 2019 (CET)
Ok, ich habe die Parameter jetzt hinter der einleitenden Beschreibung heraufplatziert, denn ich finde, dass man zuerst mal erfahren sollte, was die Vorlage überhaupt macht. ÅñŧóñŜûŝî (Ð) 13:29, 23. Dez. 2019 (CET)
Was die „Vorlage überhaupt macht“, erklärt für die Gesamt-Seiten-Angucker wie für die VisualEdior-Anwender der gemeinschaftliche Einleitungsabschnitt.
Nur dass in diesem Fall der Einleitungsabschnitt innerhalb des blauen TemplateData-Rahmens erscheint.
Wenn du findest, dass an dieser Stelle die Funktionsbeschreibung ausführlicher oder verständlicher sein solle, dann mach sie halt ausführlicher oder verständlicher – dann haben auch VisualEdior-Benutzer etwas davon und haben denselben Informationsstand. Was das Formular bei VisualEdior vielleicht sprengen würde, kannst du auf der Seitenansicht mittels <noexport> noch ausweiten.
VG --PerfektesChaos 13:36, 23. Dez. 2019 (CET)
Archivierung dieses Abschnittes wurde gewünscht von: PerfektesChaos 17:56, 4. Jun. 2021 (CEST)
Abgerufen von „https://de.wikipedia.org/w/index.php?title=Wikipedia:Lua/Werkstatt/Archiv/2019&oldid=212774026“