Hulp: Lua
Lua is een scripttaal die in maart 2013 beschikbaar kwam in de Duitstalige Wikipedia.
- De functies worden ingevoegd in een omringende klassieke sjabloon met behulp van een nieuwe
{{#invoke:}}
en vullen deze aan met algemene hulpfuncties die voorheen moeilijk te implementeren waren. - Vergeleken met wiki syntax template programmering, Lua biedt tot nu toe nauwelijks technieken in verband met tekenreeksen en grote hoeveelheden numerieke data; samen met analyse van de wiki-tekst van de weergegeven pagina.
- In MediaWiki is het verbonden via de mw: Extensie: Scribunto , die ook andere scripttalen mogelijk zou maken.
De weergave op deze helppagina's is daarentegen in principe van toepassing op elke wiki.
Sjabloon programmeren
Bel (meestal binnen een sjabloon):
{{#invoke: Modul-Titel | Funktionsname | Wert1 | Wert2 | NameX=Wert ... }}
Net als bij sjablonen kunnen de parameters een naam of een naam hebben; in principe gelden analoge regels.
- In het geval van onbekende inhoud die van buiten komt, mogen geen naamloze parameters worden gebruikt, of
1=Wert1
zoals bij sjablonen (verergerd probleem met gelijkteken ; kan leiden tot syntaxisfouten). - De retourwaarde van de aangeroepen functie is een tekenreeks met wikitekst, die op dit punt in het artikel is ingesloten.
- Voorbeeld: Module: Hallo - Demonstratie: Hallo, wereld! Dit is Lua!
- Op het moment van de functie-aanroep heeft de parser al verschillende belangrijke stappen voltooid, met name de sjabloonuitbreiding en de verwerking van extension-tags (
<ref>
,<pre>
,<nowiki>
, ...). Dus een directe uitvoer van{{Vorlage}}
alleen leiden tot de uitvoer van de tekst{{Vorlage}}
zonder de daadwerkelijke sjabloonuitbreiding. Indien nodig kan dit allemaal binnen de moduleprogrammering. - Elke keer dat
#invoke
wordt aangeroepen, wordt de uitvoeringsomgeving#invoke
. Een directe overdracht van variabelen tussen twee oproepen is niet mogelijk. - Binnen de
#invoke
de individuele oproepen naar#invoke
opeenvolgend gedaan en met behulp van dezelfde bovenliggende omgeving (die maar weinig geëvalueerd kan worden). - Verschillende integraties van de sjabloon zelf (bijvoorbeeld in een artikel) worden daarentegen parallel verwerkt en delen geen bovenliggende omgeving.
#invoke
in een encyclopedisch artikel of een algemene projectpagina is absoluut onwenselijk. Deze oproepen moeten altijd in sjablonen worden verpakt; Uitzonderingen zijn die projectpagina's die specifiek over Lua gaan ( WP: Lua / ***).
Beperkingen
- De nestdiepte en -grootte (uitbreiding) worden onvermijdelijk verminderd door Lua. Pagina's die voorheen niet konden worden weergegeven, kunnen nu worden weergegeven zonder de limieten te overschrijden.
- De tijd die nodig is voor de algehele weergave van een pagina met behulp van complexe sjabloonprogrammering kan worden teruggebracht tot ongeveer een derde als de sjabloonsyntaxis wordt vervangen door equivalente Lua-modules.
- In het geval van een pagina met veel zeer eenvoudige sjablonen daarentegen zou de prestatie kunnen verminderen als elke eenvoudige sjabloon zou worden vervangen door een Lua-gebruik: elke start van een Lua-functie kost een bepaald inschrijfgeld, dat eerst moet worden verdiend door een eerder gecompliceerde sjabloonprogrammering te vervangen. Het vervangen van een eenvoudig sjabloon was wellicht efficiënter geweest.
- Alle Lua-modules op een pagina zijn beperkt tot een cumulatieve processortijd van 10 seconden. Net als het gebruik van andere bronnen, wordt deze tijd in de HTML-broncode weergegeven als een PP-rapport van de preprocessor. In tijden van hoge serverbelasting kan de uitvoeringstijd oplopen tot vier keer. Daarom, als in gunstige tijden een totale tijd van 2 seconden wordt bereikt, moet een code-optimalisatie (nauwelijks significant te verwachten) of een opdeling van te grote pagina's worden overwogen.
- Een ander knelpunt kunnen de “dure” functies zijn. Hun aantal per totale weergegeven pagina is beperkt tot 500. Dit omvat onder andere de vraag naar het bestaan van pagina's en bestanden.
Zie ook: Help: Sjabloonbeperkingen .
Modulenaamruimte
Organisatie van de pagina's
- De broncodes bevinden zich in hun eigen modulenaamruimte: op pagina's die "modules" worden genoemd.
- Elke module bevat een of meer functies in Lua.
- Een volledige
#invoke
kan worden geladen met#invoke
,#invoke
require()
of, in geschikte gevallen,mw.loadData()
.
- Alleen pagina's uit de namespace-
Modul:
kunnen worden gebruikt voor de evaluatie.- Gebruikerssubpagina's zijn niet mogelijk; behalve die in de hiërarchie van de sjabloonspeeltuin .
- Alle subpagina's in de modulenaamruimte worden ook beschouwd als Lua-broncode en worden niet weergegeven als wikitekst. Alleen de subpagina's volgens het overeengekomen schema voor de documentatie worden als wikitekst beschouwd.
- Een pagina met Lua-broncode heeft het inhoudsmodel "
Scribunto
".
- Een documentatiepagina is gekoppeld aan elke broncodepagina en moet ook worden gebruikt. Het wordt gevormd uit de paginanaam als een subpagina
/Doku
. - Sjablonen zijn niet effectief in de Lua-broncode; SLA zou moeten worden ingesteld op WP: A / A of met een verwijzing naar de bovenkant (module) op de documentatiepagina. Directe categorisering is ook niet mogelijk.
- Modules worden beheerd als sjablonen (integratie van pagina's). Ze verschijnen ook onder "Links naar deze pagina", zelfs als ze niet zijn opgenomen met
#invoke
, maar worden aangeroepen met#invoke
require()
. Tools tellen ongeveer het aantal integraties.
Omleidingen en verschuivingen
Doorsturen van de ene modulepagina naar de andere is niet mogelijk. Een "doorsturen" zou wiki-syntaxis genereren in plaats van Lua-broncode en (in tegenstelling tot in het geval van sjablonen) alle integraties veroorzaken en require()
de module syntaxisfouten genereert; daarom kon een doorzending niet eens zonder meer worden gered.
Als de naam van een module niet langer passend lijkt, moet het bestaan van Lua-broncode onder de geprogrammeerde naam worden gegarandeerd. "Normale" diensten zijn niet mogelijk. Bij productief gebruikte modules die al van vele kanten zijn geïntegreerd, is de procedure behoorlijk omslachtig; vooral als er al meerdere ontwikkelaars bij betrokken waren.
- Maak eerst een nieuwe module onder de toekomstige naam en vul deze met de broncode.
- Als er meerdere gebruikers betrokken waren bij de programmering, moet een versie-import binnen hetzelfde project worden aangevraagd bij WP: IU .
- Dan moeten alle gebruiken worden omgezet in de nieuwe naam.
- Het gebruik in de gepresenteerde pagina's, inclusief
require()
wordt aangegeven op Special: Linklist . Deze lijst moet immers leeg zijn. - Ten slotte moet de verouderde module worden verwijderd.
Een uniforme functionaliteit kan echter worden bereikt totdat alle toepassingen zijn return require( "Modul:NeuerName" )
door als een enkele regel te houden: return require( "Modul:NeuerName" )
Zolang de module echter nog niet productief wordt gebruikt, kan deze eenvoudig worden verplaatst.
Pagina bewerken
- Bij het bewerken van de broncodepagina wordt de CodeEditor geactiveerd .
- Er wordt een foutopsporingsconsole weergegeven.
- Modules kunnen worden getest in een sjabloonomgeving (binnen een andere pagina).
Zie: Help: Lua / broncode en voorbeeld
Het opslaan van defecte Lua-modules is sinds oktober 2014 niet meer mogelijk.
Syntaxisaccentuering en regelnummers
De syntaxiselementen worden weergegeven in verschillende kleuren tot een bepaalde maximale grootte van de pagina. Sinds begin 2021 worden ook regelnummers weergegeven op codetabellen.
- Een link naar een specifieke regel is mogelijk met de fragment identifier
#L-1
,#L-2
,#L-3
etc. - Een klik op het regelnummer markeert de huidige regel en de juiste link naar deze regel wordt weergegeven in de adresregel van de browser.
- De huidige versie kan worden gekoppeld in huidige discussies.
- Omdat de voorgaande code in de loop van de tijd kan veranderen, is een PermaLink wellicht aan te raden.
De maximale grootte van pagina's met syntaxisaccentuering, die kleurcodering voor te grote pagina's voorkomt en ook voorkomt dat regelnummers worden gegenereerd.
testen
- Speelplaats
- Gratis proefversie van kleine codefragmenten voor een korte tijd.
- Voor groter ontwikkelingswerk maakt de sjabloonspeeltuin ook broncodemodules op uw eigen gebruikerspagina's mogelijk.
- Hallo
- Demonstratiemodule (Hallo, Wereld!) -
Hallo, Welt! Dies ist Lua!
- Alle gebruikers
- voor bètatests door meerdere gebruikers met
-
Modul:Benutzerin:
xxxxxxxxxxxx -
Modul:Benutzer:
xyxyxyxyxyxy - Subpagina's voor gebruikersmodules zijn mogelijk.
- Daar moet ook een pagina worden aangemaakt.
-
- Sjabloon speeltuin
- Alle gebruikers kunnen de sjabloonspeeltuin op hun gebruikerspagina's gebruiken om hun eigen testmodules te beheren. Door middel van de gebruikersscripteditor is dan inhoud beschikbaar en de code-editor beschikbaar.
Daarnaast kunnen testwiki:, test2wiki: (met uw eigen SUL-account ) en de.wikipedia.beta
( apart account vereist ) worden gebruikt. In de echte dewiki
zouden dan half volwassen productieve versies moeten verschijnen.
Programmeren in Lua
Zie help: Lua / programmeren met speciale onderwerpen
- Module in de wiki - module in de context van een wikipagina
- Module voor een specifieke sjabloon
- Snaren
- mw object - functiebibliotheken
- Links - Pagina's en URL
- Omgeving - huidig wiki-project
- internationalisering
Voor de Lua-taal in het algemeen, zie de handleidingen die als weblinks worden gegeven.
Vertegenwoordiging van de broncode
- De broncode kan in tekstpagina's worden
<syntaxhighlight lang="lua">
met<syntaxhighlight lang="lua">
. - De inhoud van een hele module kan in kleur worden weergegeven met:
-
{{#tag:syntaxhighlight |{{Modul:Hello}}| lang=lua}}
-
Extra informatie
- Originele Lua-handleiding; bevat onderdelen die niet mogelijk zijn op een wikiserver:
- Lua 5.1 Referentiehandleiding - lua.org (Engels, Portugees)
- lua.coders-online.net (Duitse vertaling van de handleiding; JavaScript vereist)
- Codeerconventies - coderingsstandaard
- Lua vs Javascript - Waarom is voor Lua gekozen en niet voor JavaScript ? (Engels)
- Codevoorbeelden:
- lua-users.org (Engels)
- ELUA / * - implementatie op de wiki-server