Module:Arguments/doc: Difference between revisions
From The Kodiak Republic Wiki
m
82 revisions imported from dev:Module:Arguments/doc
No edit summary |
m (82 revisions imported from dev:Module:Arguments/doc) |
||
(43 intermediate revisions by 29 users not shown) | |||
Line 1:
This module provides easy processing of arguments passed from <code>#invoke</code>. It is a meta-module, meant for use by other modules, and should not be called from <code>#invoke</code> directly. Its features include:▼
▲This module provides easy processing of arguments passed from #invoke. It is a meta-module, meant for use by other modules, and should not be called from #invoke directly. Its features include:
* Easy trimming of arguments and removal of blank arguments.
* Arguments can be passed by both the current frame and by the parent frame at the same time. (More details below.)
* Arguments can be passed in directly from another Lua module or from the debug console.
* Most features can be customized.
Line 12 ⟶ 9:
First, you need to load the module. It contains one function, named <code>getArgs</code>.
<
local getArgs = require('Module:Arguments').getArgs
</syntaxhighlight>
In the most basic scenario, you can use getArgs inside your main function. The variable <code>args</code> is a table containing the arguments from #invoke. (See below for details.)
<
local getArgs = require('Module:Arguments').getArgs
local p = {}
Line 28 ⟶ 25:
return p
</syntaxhighlight>
=== Recommended practice ===
However, the recommended practice is to use a function just for processing arguments from #invoke. This means that if someone calls your module from another Lua module you don't have to have a frame object available, which improves performance.
<
local getArgs = require('Module:Arguments').getArgs
local p = {}
Line 46 ⟶ 44:
return p
</syntaxhighlight>
The way this is called from a template is <code><nowiki>{{#invoke:Example|main}}</nowiki></code> (optionally with some parameters like <code><nowiki>{{#invoke:Example|main|arg1=value1|arg2=value2}}</nowiki></code>), and the way this is called from a module is <syntaxhighlight lang=lua inline>require('Module:Example')._main({arg1 = 'value1', arg2 = value2, 'spaced arg3' = 'value3'})</syntaxhighlight>. What this second one does is construct a table with the arguments in it, then gives that table to the p._main(args) function, which uses it natively.
=== Multiple functions ===
If you want multiple functions to use the arguments, and you also want them to be accessible from #invoke, you can use a wrapper function.
<
local getArgs = require('Module:Arguments').getArgs
local p = {}▼
local function makeInvokeFunc(funcName)
Line 59 ⟶ 62:
end
end
▲local p = {}
p.func1 = makeInvokeFunc('_func1')
Line 75 ⟶ 76:
return p
</syntaxhighlight>
=== Options ===
Line 81 ⟶ 82:
The following options are available. They are explained in the sections below.
<
local args = getArgs(frame, {
trim = false,
Line 98 ⟶ 99:
noOverwrite = true
})
</syntaxhighlight>
=== Trimming and removing blanks ===
Line 108 ⟶ 109:
However, sometimes you want to use blank arguments as input, and sometimes you want to keep additional whitespace. This can be necessary to convert some templates exactly as they were written. If you want to do this, you can set the <code>trim</code> and <code>removeBlanks</code> arguments to <code>false</code>.
<
local args = getArgs(frame, {
trim = false,
removeBlanks = false
})
</syntaxhighlight>
=== Custom formatting of arguments ===
Line 120 ⟶ 121:
Example 1: this function preserves whitespace for the first positional argument, but trims all other arguments and removes all other blank arguments.
<
local args = getArgs(frame, {
valueFunc = function (key, value)
Line 134 ⟶ 135:
end
})
</syntaxhighlight>
Example 2: this function removes blank arguments and converts all arguments to lower case, but doesn't trim whitespace from positional parameters.
<
local args = getArgs(frame, {
valueFunc = function (key, value)
Line 150 ⟶ 151:
end
})
</syntaxhighlight>
Note: the above functions will fail if passed input that is not of type <code>string</code> or <code>nil</code>. This might be the case if you use the <code>getArgs</code> function in the main function of your module, and that function is called by another Lua module. In this case, you will need to check the type of your input. This is not a problem if you are using a function specially for arguments from #invoke (i.e. you have <code>p.main</code> and <code>p._main</code> functions, or something similar).
Example 1:
<
local args = getArgs(frame, {
valueFunc = function (key, value)
Line 173 ⟶ 175:
end
})
</syntaxhighlight>
Example 2:
<
local args = getArgs(frame, {
valueFunc = function (key, value)
Line 191 ⟶ 193:
end
})
</syntaxhighlight>
Also, please note that the <code>valueFunc</code> function is called more or less every time an argument is requested from the <code>args</code> table, so if you care about performance you should make sure you aren't doing anything inefficient with your code.
Line 200 ⟶ 201:
Arguments in the <code>args</code> 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 <code>Module:ExampleArgs</code>. This module prints the first two positional arguments that it is passed.
<
local getArgs = require('Module:Arguments').getArgs
local p = {}
Line 217 ⟶ 218:
return p
</syntaxhighlight>
<code>Module:ExampleArgs</code> is then called by <code>Template:ExampleArgs</code>, which contains the code <code><nowiki>{{#invoke:ExampleArgs|main|firstInvokeArg}}</nowiki></code>. This produces the result "firstInvokeArg".
Line 297:
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 [[w:Template:Side box]] (excluding content in
Wrappers can be specified either as a string, or as an array of strings.
<
local args = getArgs(frame, {
wrappers = 'Template:Wrapper template'
})
</syntaxhighlight>
<
local args = getArgs(frame, {
wrappers = {
Line 316:
}
})
</syntaxhighlight>
Notes:
# 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.
# The ''wrappers'' option effectively changes the default of the ''frameOnly'' and ''parentOnly'' options. If, for example, ''parentOnly'' were explicitly set to
# If the ''wrappers'' option is set and no parent frame is available, the module will always get the arguments from the frame passed to <code>getArgs</code>.
Line 327:
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'
</syntaxhighlight>
It is possible to alter this behaviour with the <code>readOnly</code> and <code>noOverwrite</code> options. If <code>readOnly</code> is set then it is not possible to write any values to the args table at all. If <code>noOverwrite</code> 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.
Line 335:
=== Ref tags ===
This module uses [[mw:Extension:Scribunto/Lua reference manual#Metatables|metatables]] to fetch arguments from #invoke. This allows access to both the frame arguments and the parent frame arguments without using the <code>pairs()</code> function. This can help if your module might be passed
As soon as
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 <code>pairs(args)</code> elsewhere in your module, however.
Line 343:
=== 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 <code>#</code> operator, the <code>next()</code> 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.
|