Navigation menu

Module:Arguments/doc: Difference between revisions

From The Kodiak Republic Wiki

m
82 revisions imported from dev:Module:Arguments/doc
m (→‎Recommended practice: escape examples)
m (82 revisions imported from dev:Module:Arguments/doc)
 
(8 intermediate revisions by 6 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:
{{High-use|22800000|all-pages = yes}}
{{Used in system}}
{{Module rating|p}}
 
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.)
Line 159 ⟶ 155:
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).
 
{{cot|Examples 1 and 2 with type checking}}:
 
Example 1:
<syntaxhighlight lang="lua">
Line 197 ⟶ 194:
})
</syntaxhighlight>
{{cob}}
 
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 205 ⟶ 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.
 
{{cot|Module:ExampleArgs code}}:
<syntaxhighlight lang="lua">
local getArgs = require('Module:Arguments').getArgs
Line 223 ⟶ 219:
return p
</syntaxhighlight>
{{cob}}
 
<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 302 ⟶ 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 {{tag|&lt;noinclude}}&gt; tags) is <code><nowiki>{{#invoke:Side box|main}}</nowiki></code>. 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 {{para<nowiki>|text|=Some text}}</nowiki> in the code <code><nowiki>{{#invoke:Side box|main|text=Some text}}</nowiki></code> would be ignored completely, no matter what page it was used from. By using the <code>wrappers</code> option to specify 'Template:Side box' as a wrapper, we can make <code><nowiki>{{#invoke:Side box|main|text=Some text}}</nowiki></code> work from most pages, while still not requiring that the module check for arguments on the [[w:Template:Side box]] page itself.
 
Wrappers can be specified either as a string, or as an array of strings.
Line 325 ⟶ 320:
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 false0 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.
# 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 340 ⟶ 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 {{tag|&lt;ref}}&gt; tags as input.
 
As soon as {{tag|&lt;ref}}&gt; 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 without any number linking to it. This has been a problem with modules that use <code>pairs()</code> 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 <code>pairs(args)</code> elsewhere in your module, however.
Line 348 ⟶ 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.<includeonly>{{#ifeq:{{SUBPAGENAME}}|sandbox||
[[Category:Lua metamodules]]
}}</includeonly>
Cookies help us deliver our services. By using our services, you agree to our use of cookies.