Ugrás a tartalomhoz

Modul:Arguments/doc

A Wikipédiából, a szabad enciklopédiából
A lap korábbi változatát látod, amilyen Nemethyd (vitalap | szerkesztései) 2018. október 12., 14:32-kor történt szerkesztése után volt. Ez a változat jelentősen eltérhet az aktuális változattól. (A paraméterek testreszabott formázása)

Ez a Modul:Arguments dokumentációs lapja

Ez a modul az #invoke-kal hívott modulok paramétereinek egyszerű feldolgozását segíti. Ez egy meta-modul, azaz más modulok használják, ezért az #invoke-kal történő közvetlen hívása értelmetlen. Képességei:

  • A paraméterek kezdő és záró szőközöktől való megtisztítása (trim). Az üres paraméterek eldobása
  • A paramétereket az aktuális és a szülő feldolgozókeret is egyszerre át tudja adni. (Részletek lejjebb.)
  • A paraméterek más közvetlenül Lua modulból vagy egy hibakereső (debug) konzolról is átadhatók.
  • A paraméterek, akkor kerülnek átvételre, amikor szükség van rájuk, ezzel a referencia tag-ekből adódó egyes problémák elkerülhetőek.
  • A legtöbb képesség testreszabható.

Alap felhasználási mód

Legelőször be kell tölteni a modult. Egyetlen függvényt a getArgs-ot tartalmazza.

local getArgs = require('Modul:Arguments').getArgs

A legegyszerűbb esetben a getArgs a hívó modul fő függvényből meghívható. Az args változó valójában egy tábla, amely az #invoke-ból jövő paramétereket tartalmazza. (Részletek lejjebb.)

local getArgs = require('Modul:Arguments').getArgs
local p = {}

function p.main(frame)
	local args = getArgs(frame)
	-- ide jön a főmodul kódja.
end

return p

A javasolt eljárás az, hogy a a függvényt elsősorban az #invoke-ból jövő paraméterek kezelésére használjuk. Ezt azért javasolt, mert ha modulunkat egy másik Lua-modul közvetlenül hívja, mek kell külön keret-objektumot alkalmazni, ez pedig növeli a kód futási teljesítményét.

local getArgs = require('Modul:Arguments').getArgs
local p = {}

function p.main(frame)
	local args = getArgs(frame)
	return p._main(args)
end

function p._main(args)
	-- a fő kód ide kerüljön.
end

return p

Ha több függvényben fel akarjuk használni az #invoke-ból elérhető módon a paramétereket, akkor egy külön függvénybe csomagolhatjuk a getArgs-ot.

local getArgs = require('Modul:Arguments').getArgs

local function makeInvokeFunc(funcName)
	return function (frame)
		local args = getArgs(frame)
		return p[funcName](args)
	end
end

local p = {}

p.func1 = makeInvokeFunc('_func1')

function p._func1(args)
	-- Az első függvény kódja...
end

p.func2 = makeInvokeFunc('_func2')

function p._func2(args)
	-- a második függvény kódja
end

return p

Opciók

A következő, az alábbi szakaszokban elmygarázott opciók érhetők el:

local args = getArgs(frame, {
	trim = false,
	removeBlanks = false,
	valueFunc = function (key, value)
		-- a paramétreket feldolgozó kód
	end,
	frameOnly = true,
	parentOnly = true,
	parentFirst = true,
	wrappers = {
		'Sablon:Burkoló sablon',
		'SAblon:Másik burkoló sablon'
	},
	readOnly = true,
	noOverwrite = true
})

Üres szóközök elhagyása és eltávolítása

Az üres paraméterek problémájában gyakran beleütköznek a Médiiawiki sablonokat Lua-kódba áttevőkezdő programozók. A sablon szintaxisában az üres karakterláncok, és a csak fehér karakterekből álló láncokat hamis értékűnek számítanak. Ugyanakkor a Luá-ban ezeket a karakterláncokat igaz értékűnek tekintjük. Ha tehát nem figyelünk ezekre a különbségekre, akkor előfordulhat, hogy a Lua-modulban igaznak teküntünk valamit, amit valójában hamis értékűnek kellene vennünk. Hogy az ilyen helyzeteket elkerülhessük, az a modul alapértelmezésben eltávolítja az üres paramétereket.

Hasonló gondot okozhatnak a névtelen paraméterek is. Jóllehet a fehér karakterek el vannak távolítva az #invoke-ból nevesített paraméterek elejéről és végéről, ez nem történik meg a névtelen, ún. pozicionális paraméterek esetén. A legtöbbször nincs szükség ezekre a szélen lévő fehér karakterekre, ezért ez a modul alapértelmezésben eltávolítja azokat. Ha mégis szükség van az üres paraméterekre, illetve a paraméterszéleken megtalálható fehér karakterekre, például bizonyos sablonok működésének pontos lemásolása céljából, akkor a trim illetve removeBlanks paramétekreket hamisra (false) kell állítani.

local args = getArgs(frame, {
	trim = false,
	removeBlanks = false
})

A paraméterek testreszabott formázása

Néha bizonyos üres paramétereket el kívánunk hagyni, másokat azonban nem, vagy esetleg minden névtelen paramétert kisbetűssé kívánunk tenni. Ilyen feladatokat a valueFunc kapcsoló segítségével tudunk megoldani. A kapcsoló bemenete a egy kétváltozós függvény: key és value. A függvény visszatérési értéke az args táblában a key mezőben található érték.

1. Példa: A függvény az első névtelen paraméter értékét pontosan megtartja, az összes többi paraméter széleiről eltávolítja a fehér karaktereket, és a többi üres paramétert pedig elhagyja.

local args = getArgs(frame, {
	valueFunc = function (key, value)
		if key == 1 then
			return value
		elseif value then
			value = mw.text.trim(value)
			if value ~= '' then
				return value
			end
		end
		return nil
	end
})

2. Példa: Eza függvény elhagyja az üres paramétereket és valamennyi értékét kisbetűsíti, de nem szélezi a névtelen paramétereket.

local args = getArgs(frame, {
	valueFunc = function (key, value)
		if not value then
			return nil
		end
		value = mw.ustring.lower(value)
		if mw.ustring.find(value, '%S') then
			return value
		end
		return nil
	end
})

Megjegyzés: a fenti függvény hibára fut, ha a bemenete nem string típusó, vagy nem nil. Ez olyankor fordulhat elő, ha a getArgs függvényt modulunk fő függvényében használjuk, amelyet viszont egy másik Lua-modul hív nmeg. Ebben az esetben ellenőrizni kell a bemeneti paraméter típusát. Ilyen gond nem lép fel, he egy speciális függvényt használunk fel az #invoke paramétereinek beolvasására. (pl. p.main a fő kódunk és a p._main speciális függvényt alkalmazzuk.

Vegyük észre, hogy valueFunc függvényt szinte minden alkalommal meghívjuk, ha szükségünk van a args tábla egy elemére, ha szempont számunkra a kód hatékonysága, akkor figyeljük, hogy ne maradjanak a kódunkban rossz hatékonyságú elemek.

Frames and parent frames

Arguments in the args table can be passed from the current frame or from its parent frame at the same time. To understand what this means, it is easiest to give an example. Let's say that we have a module called Modul:ExampleArgs. This module prints the first two positional arguments that it is passed.

Modul:ExampleArgs is then called by Template:ExampleArgs, which contains the code {{#invoke:ExampleArgs|main|firstInvokeArg}}. This produces the result "firstInvokeArg".

Now if we were to call Template:ExampleArgs, the following would happen:

Code Result
{{ExampleArgs}} firstInvokeArg
{{ExampleArgs|firstTemplateArg}} firstInvokeArg
{{ExampleArgs|firstTemplateArg|secondTemplateArg}} firstInvokeArg secondTemplateArg

There are three options you can set to change this behaviour: frameOnly, parentOnly and parentFirst. If you set frameOnly then only arguments passed from the current frame will be accepted; if you set parentOnly then only arguments passed from the parent frame will be accepted; and if you set parentFirst then arguments will be passed from both the current and parent frames, but the parent frame will have priority over the current frame. Here are the results in terms of Template:ExampleArgs:

frameOnly
Code Result
{{ExampleArgs}} firstInvokeArg
{{ExampleArgs|firstTemplateArg}} firstInvokeArg
{{ExampleArgs|firstTemplateArg|secondTemplateArg}} firstInvokeArg
parentOnly
Code Result
{{ExampleArgs}}
{{ExampleArgs|firstTemplateArg}} firstTemplateArg
{{ExampleArgs|firstTemplateArg|secondTemplateArg}} firstTemplateArg secondTemplateArg
parentFirst
Code Result
{{ExampleArgs}} firstInvokeArg
{{ExampleArgs|firstTemplateArg}} firstTemplateArg
{{ExampleArgs|firstTemplateArg|secondTemplateArg}} firstTemplateArg secondTemplateArg

Notes:

  1. If you set both the frameOnly and parentOnly options, the module won't fetch any arguments at all from #invoke. This is probably not what you want.
  2. In some situations a parent frame may not be available, e.g. if getArgs is passed the parent frame rather than the current frame. In this case, only the frame arguments will be used (unless parentOnly is set, in which case no arguments will be used) and the parentFirst and frameOnly options will have no effect.

Wrappers

The wrappers option is used to specify a limited number of templates as wrapper templates, that is, templates whose only purpose is to call a module. If the module detects that it is being called from a wrapper template, it will only check for arguments in the parent frame; otherwise it will only check for arguments in the frame passed to getArgs. This allows modules to be called by either #invoke or through a wrapper template without the loss of performance associated with having to check both the frame and the parent frame for each argument lookup.

For example, the only content of Template:Side box (excluding content in noinclude tags) is {{#invoke:Side box|main}}. There is no point in checking the arguments passed directly to the #invoke statement for this template, as no arguments will ever be specified there. We can avoid checking arguments passed to #invoke by using the parentOnly option, but if we do this then #invoke will not work from other pages either. If this were the case, the |text=Some text in the code {{#invoke:Side box|main|text=Some text}} would be ignored completely, no matter what page it was used from. By using the wrappers option to specify 'Template:Side box' as a wrapper, we can make {{#invoke:Side box|main|text=Some text}} work from most pages, while still not requiring that the module check for arguments on the Template:Side box page itself.

Wrappers can be specified either as a string, or as an array of strings.

local args = getArgs(frame, {
	wrappers = 'Template:Wrapper template'
})


local args = getArgs(frame, {
	wrappers = {
		'Template:Wrapper 1',
		'Template:Wrapper 2',
		-- Any number of wrapper templates can be added here.
	}
})

Notes:

  1. The module will automatically detect if it is being called from a wrapper template's /sandbox subpage, so there is no need to specify sandbox pages explicitly.
  2. The wrappers option effectively changes the default of the frameOnly and parentOnly options. If, for example, parentOnly were explicitly set to false with wrappers set, calls via wrapper templates would result in both frame and parent arguments being loaded, though calls not via wrapper templates would result in only frame arguments being loaded.
  3. If the wrappers option is set and no parent frame is available, the module will always get the arguments from the frame passed to getArgs.

Writing to the args table

Sometimes it can be useful to write new values to the args table. This is possible with the default settings of this module. (However, bear in mind that it is usually better coding style to create a new table with your new values and copy arguments from the args table as needed.)

args.foo = 'some value'

It is possible to alter this behaviour with the readOnly and noOverwrite options. If readOnly is set then it is not possible to write any values to the args table at all. If noOverwrite is set, then it is possible to add new values to the table, but it is not possible to add a value if it would overwrite any arguments that are passed from #invoke.

Ref tags

This module uses metatables to fetch arguments from #invoke. This allows access to both the frame arguments and the parent frame arguments without using the pairs() function. This can help if your module might be passed ref tags as input.

As soon as ref tags are accessed from Lua, they are processed by the MediaWiki software and the reference will appear in the reference list at the bottom of the article. If your module proceeds to omit the reference tag from the output, you will end up with a phantom reference - a reference that appears in the reference list, but no number that links to it. This has been a problem with modules that use pairs() to detect whether to use the arguments from the frame or the parent frame, as those modules automatically process every available argument.

This module solves this problem by allowing access to both frame and parent frame arguments, while still only fetching those arguments when it is necessary. The problem will still occur if you use pairs(args) elsewhere in your module, however.

Known limitations

The use of metatables also has its downsides. Most of the normal Lua table tools won't work properly on the args table, including the # operator, the next() function, and the functions in the table library. If using these is important for your module, you should use your own argument processing function instead of this module.