Diese Projektseite stellt Möglichkeiten dar, bei der Programmierung von Lua-Modulen das Basis-Konzept einer Trennung von Programm und Daten umzusetzen.

Die Trennung von Programm und Daten gehört zum Stoff des ersten Semesters eines Informatikstudiums.

Vorteile:

• Wartbarkeit verbessert,
• Übersichtlichkeit erhöht,
• Robustheit gesteigert,
• Portabilität ermöglicht,
• Flexibilität unterstützt.

Grundsätzlich werden Parameter mit konstanten Werten, welche eine zukünftig möglicherweise veränderliche Konfiguration abbilden, sowie sämtliche veränderlichen Textbausteine, die auch von menschlichen Sprachen abhängen, in der Strukturierung getrennt von den prozeduralen, algorithmischen Beziehungen.

• Dadurch können die Konfigurationsdaten an einer zentralen und übersichtlich zugänglichen Stelle gesammelt und auch dokumentiert werden. Wären sie hard-coded überall in den Instruktionen verteilt, wären viel schwieriger alle Vorkommen aufzufinden und bei entstehendem Bedarf anzupassen. Nach einigen Jahren und durch die Nachfolgenden würde das zur Herausforderung.
• Zahlen oder Kennbuchstaben erhalten sprechende Bezeichner. Dadurch wird die Bedeutung der Anweisungen verständlicher. Irrtümer werden vermieden, Fehler treten offenkundig hervor.
• Standardwerte können als Vorgaben definiert werden; bei abweichendem besonderen Bedarf kann die Wirkung der Software von außen durch individuell zugewiesene Parameter beeinflusst werden, ohne dass die Programmierung verändert werden müsste.
• Weil der funktionale Teil ggf. auch auf eigenen Seiten gekapselt ist, während Konfigurationsdaten auf anderen Seiten im Wiki liegen, kann eine aktualisierte Programmierung global verteilt werden, ohne dass sie in jedem einzelnen Projekt mit jeder neuen Version angepasst werden müsste. Siehe dazu Internationalisierung.

Die Funktionen der Systembibliotheken liefern diverse global gepflegte Konfigurationsdaten über das aktuelle Wiki.

Im aktuellen Modul können Werte statisch zugewiesen werden, oder auch abhängig von der aktuellen Seite dynamisch ermittelt werden.

• Diese local-Zuweisungen sollten geschlossen zu Beginn des Quelltextes erfolgen, damit sie leicht und vollständig wiedergefunden und gepflegt werden können.
• Falls nicht selbsterklärend, kann jede Zuweisung auch kommentiert und damit dokumentiert werden.
• Es bietet sich an, die lokalen Zuweisungen als table zu gruppieren. Damit wird bei der späteren Verwendung innerhalb einer Funktion deutlich dass es sich um bestimmte Blöcke der modulweiten Konfiguration handelt, etwa Projektstruktur oder sprachliche Textbausteine.
• Die Werte können ggf. auch durch Aufrufparameter des #invoke oder externe Seiten überschrieben werden.

Beispiel: Modul:TemplateData

Dies ist Mittel der Wahl für eine Programmierung, die in mehreren Wikis wiederverwendet werden soll.

• Es wird ein Modul im Modul-Namensraum hinterlegt.
• Die Funktion mw.loadData() ermöglicht dann die Einbindung in andere Module.
• Das Ergebnis wird immer eine table sein und kann eine Struktur aus beliebig vielen atomaren Werten sowie anderer table enthalten.

Vorteile

• Das Resultat wird nur einmal pro dargestellter Seite kompiliert und das Ergebnis dann dieser aktuellen dargestellten Seite zugeordnet. Damit kann es von mehreren #invoke-Einbindungen wiederverwendet werden.
• Die Ermittlung des Resultats kann dynamisch, also durch Auswertung von Funktionen betreffend der aktuell dargestellten Seite, externer Seiten oder anderer veränderlicher Bedingungen erfolgen.
• Für späteres Wartungs- und Pflegepersonal wird ein übersichtliches und eher kleines Modul dargestellt, das sich leichter überblicken lässt und auch ohne Lua-Erfahrung die Schwelle zur Anpassung einer Zeichenkette oder Zahl senkt.

Nachteile

• Ähnlich JSON darf das Resultat keine Programmierungen vom Typ function enthalten, sondern nur reine Daten: nil, boolean, number, string, table

Beispiel: Modul:URIutil/urn

Mittels require() kann ein anderes Modul eingebunden werden.

Vorteile

• Gegenüber einem mw.loadData() kann das Resultat auch Funktionen enthalten.

Nachteile

• Zurzeit gibt es keine Hinterlegung kompilierter Versionen pro Seite.

Beispiel: Modul:Vorlage:Runeberg/NF‎

Seit Oktober 2022 ist die Bibliotheksfunktion mw.loadJsonData() nutzbar.

• Konzeptionell entspricht dies einer per mw.loadData() einbindbaren Lua-Seite.
• Die Seite kann auch im Modul-Namensraum angelegt werden. Es bietet sich eine Unterseite des versorgten Moduls an.
• Die Syntax ist JSON statt Lua.
• Auch aus jedem anderen Namensraum kann eine .json-Seite genutzt werden, etwa geteilt mit Gadgets.

Benutzung: tbl = mw.loadJsonData( seitenname )

• Das Ergebnis ist eine table.

Vorteile

• Die JSON-Notation ist externem Wartungspersonal möglicherweise geläufiger als Lua.
• Skripte in JavaScript können die Seite ebenfalls mit einer Standardfunktion auslesen und die Daten nutzen.

Nachteile

• Anders als ein mw.loadData() kann die Seite nur echte Konstanten enthalten, also keine Funktionen auswerten.
• Kommentare sind unzulässig; müssten ggf. als Elemente von Objekten wirksam eingebracht werden.

Beispiel: Modul:JSTOR/config.json

Eine beliebige Seite in Wikitext kann ausgelesen, insbesondere aber transkludiert werden.

Vorteile

• Es gibt mehr mit der Vorlagensyntax Vertraute als Lua-Personal.
• Es kann sowohl zur Vereinbarung von Parameterwerten innerhalb der Lua-Programmierung genutzt werden, oder die externe Vorlage wird zur Nachbereitung des Lua-Resultats als Ergebnis der Lua-Funktion verwendet.

Nachteile

• Nur der Datentyp „Zeichenkette“ ist primäres Resultat.
• Weniger effizient in Auswertung und erforderlicher Programmierung zwecks Parsen der Zeichenketten.

Beispiel: Vorlage:Seitenbewertung/Darstellung eingebunden durch Modul:Vorlage:Seitenbewertung

Vorteile

• Einige WP:Systemnachrichten sind womöglich bereits global und lokal definiert und können dann genutzt werden, etwa Textfragmente.

Nachteile

• Nur Admins können Systemnachrichten anlegen und pflegen.
• Der Namensraum ist nicht dafür ausgelegt, eine Vielzahl von Textfragmenten und womöglich Einzeldaten für beliebige Vorlagen zu organisieren.
• In ein anderes Wiki ist dies nicht zu übertragen, und dort wären für die Einrichtung und Pflege wieder Adminrechte erforderlich.

Im Namensraum Data:*.tab auf Wikimedia Commons können Seiten im JSON-Format hinterlegt werden, die alle Wikis lokal einbinden und auslesen können.

• Mittels mw.ext.data.get() kann die Tabelle bezogen auf die Sprache des aktuellen Wikis oder für alle Sprachen abgerufen werden.

Vorteile

• Die Daten können global zentral gepflegt und genutzt werden.
• Einzelne Wikis brauchen sich nicht um eine Aktualisierung und Verteilung zu bemühen.
• Größere Datenmengen unterliegen keinen Beschränkungen wie etwa Wikidata.
• Skripte in JavaScript können die Seite ebenfalls mit einer Standardfunktion auslesen und nutzen.

Nachteile

• Das Format .tab erlaubt keine Felder/Maps als Komponenten, sondern nur atomare Datenspalten. Allerdings gibt es den Typ „Lokalisiert“, der eine Tabelle für Zeichenketten nach Sprachcode erlaubt.
• Die globale Definition ist schwieriger zu beobachten und zu überwachen. Ggf. können Seiten jedoch unter den Schutz von template editors gestellt werden, wenn wenig Änderungsbedarf zu erwarten ist.

Eine globale Zusammenstellung kann einmalig in mw.loadData() importiert und dort unter lokalen Bedingungen aufbereitet, gefiltert und einmalig vorverarbeitet werden.

Beispiel: commons:Data:ISO15924/rtl.tab

Aus Wikidata können beliebige Eigenschaften eines Items (oder auch anderer Objekte) ausgelesen werden; siehe mw:Extension:Wikibase Client/Lua.

Vorteile

• Mitbenutzung anderweitig gepflegter und aktualisierter Daten.
• Globale Aktualisierung und Nutzung.
• Beliebige Arten der Information; als Zeichenkette.

Nachteile

• Die Anzahl sämtlicher unterschiedlicher Objekte in der aktuell dargestellten Seite ist beschränkt (400); für sämtliche Anwendungen. Das kann leicht zum Problem werden, wenn eine Liste von Gegenständen befüllt werden soll. Generell gibt es Performance-Probleme, wenn viele Objekte abgerufen werden müssen; die Anzahl ist deshalb kaum zu steigern.
• Die Beobachtung und Verfolgung der Änderungsgeschichte bei einer großen Zahl von Datenelementen ist extrem schwierig, weil jede Zahl oder Textelement innerhalb eines anderen Objekts steht, zwischen vielen anderen Eigenschaften dieses Objekts. Auf die Korrektheit der Daten und ihrer Veränderungen ist deshalb kein Verlass.

• Internationalisierung