Module:Arguments/doc - Revision history

GKNishimoto at 22:01, 9 May 2025

2025-05-09T22:01:23Z

← Previous revision		Revision as of 22:01, 9 May 2025
Line 3:		Line 3:
	{{cascade-protected template\|page=module}}		{{cascade-protected template\|page=module}}

	This module provides easy processing of arguments passed from <code>#invoke</code>.~~hhhhhuh~~ It is a meta-module, meant for use by other modules, and should not be called from <code>#invoke</code> directly (for a module directly invocable by templates you might want to have a look at {{ml\|params\|}}). Its features include:		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 (for a module directly invocable by templates you might want to have a look at {{ml\|params\|}}). Its features include:
	* Easy trimming of arguments and removal of blank arguments.		* 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 by both the current frame and by the parent frame at the same time. (More details below.)
Line 482:		Line 482:
	=== Known limitations ===		=== 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 ~~argumuhueutyyunt~~ processing function instead of this		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]]		[[Category:Lua metamodules]]
	}}</includeonly>		}}</includeonly>

2804:389:F2A8:C429:B0DA:BBFF:FE73:B260: /* Known limitations */

2025-05-09T20:09:41Z

Known limitations

← Previous revision		Revision as of 20:09, 9 May 2025
Line 482:		Line 482:
	=== Known limitations ===		=== 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\|\|~~		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 argumuhueutyyunt processing function instead of this
	[[Category:Lua metamodules]]		[[Category:Lua metamodules]]
	}}</includeonly>		}}</includeonly>

2804:389:F2A8:C429:B0DA:BBFF:FE73:B260 at 20:08, 9 May 2025

2025-05-09T20:08:55Z

← Previous revision		Revision as of 20:08, 9 May 2025
Line 3:		Line 3:
	{{cascade-protected template\|page=module}}		{{cascade-protected template\|page=module}}

	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 (for a module directly invocable by templates you might want to have a look at {{ml\|params\|}}). Its features include:		This module provides easy processing of arguments passed from <code>#invoke</code>.hhhhhuh It is a meta-module, meant for use by other modules, and should not be called from <code>#invoke</code> directly (for a module directly invocable by templates you might want to have a look at {{ml\|params\|}}). Its features include:
	* Easy trimming of arguments and removal of blank arguments.		* 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 by both the current frame and by the parent frame at the same time. (More details below.)

John of Reading: Reverted 1 edit by 41.90.172.255 (talk): Rv scribble

2025-01-26T17:52:58Z

Reverted 1 edit by 41.90.172.255 (talk): Rv scribble

← Previous revision		Revision as of 17:52, 26 January 2025
Line 1:		Line 1:
	~~{{angle bracket\|}}~~{{Used in system}}		{{Used in system}}
	{{Module rating\|p}}		{{Module rating\|p}}
	{{cascade-protected template\|page=module}}		{{cascade-protected template\|page=module}}
Line 12:		Line 12:

	First, you need to load the module. It contains one function, named <code>getArgs</code>.		First, you need to load the module. It contains one function, named <code>getArgs</code>.

	d₩™◌₳₨₨ḌḍMĖIصŋŋŋɛərɛər
	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
	local getArgs = require('Module:Arguments').getArgs		local getArgs = require('Module:Arguments').getArgs

41.90.172.255 at 17:04, 26 January 2025

2025-01-26T17:04:58Z

← Previous revision		Revision as of 17:04, 26 January 2025
Line 1:		Line 1:
	{{Used in system}}		{{angle bracket\|}}{{Used in system}}
	{{Module rating\|p}}		{{Module rating\|p}}
	{{cascade-protected template\|page=module}}		{{cascade-protected template\|page=module}}
Line 12:		Line 12:

	First, you need to load the module. It contains one function, named <code>getArgs</code>.		First, you need to load the module. It contains one function, named <code>getArgs</code>.
			d₩™◌₳₨₨ḌḍMĖIصŋŋŋɛərɛər

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
	local getArgs = require('Module:Arguments').getArgs		local getArgs = require('Module:Arguments').getArgs

Explorer09: /* Options */ Italicize "firstInvokeArg" in the examples. This help identifying the frame source of the arguments easier.

2024-11-18T09:54:47Z

Options: Italicize "firstInvokeArg" in the examples. This help identifying the frame source of the arguments easier.

← Previous revision		Revision as of 09:54, 18 November 2024
Line 241:		Line 241:
	{{cob}}		{{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"~~.		<code>Template:ExampleArgs</code> contains the code <code><nowiki>{{#invoke:ExampleArgs\|main\|''firstInvokeArg''}}</nowiki></code>.

	Now if we were to call <code>Template:ExampleArgs</code>, the following would happen:		Now if we were to call <code>Template:ExampleArgs</code>, the following would happen:
Line 249:		Line 249:
	! style="width: 60%;" \| Code		! style="width: 60%;" \| Code
	! style="width: 40%;" \| Result		! style="width: 40%;" \| Result
			\|-
			\| <pre>{{#invoke:ExampleArgs\|main\|''firstInvokeArg''}}

			(call #invoke directly without template)</pre>
			\| ''firstInvokeArg''

			(call #invoke directly without template)
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>
	\| firstInvokeArg secondTemplateArg		\| ''firstInvokeArg'' secondTemplateArg
	\|}		\|}

Line 269:		Line 276:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|}		\|}

Line 301:		Line 308:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
Line 372:		Line 379:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>
	\| firstInvokeArg secondTemplateArg		\| ''firstInvokeArg'' secondTemplateArg
	\|}		\|}

Line 388:		Line 395:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
Line 407:		Line 414:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|}		\|}

Line 423:		Line 430:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg\|secondTemplateArg}}</nowiki></code>
	\| firstInvokeArg secondTemplateArg		\| ''firstInvokeArg'' secondTemplateArg
	\|}		\|}

Line 439:		Line 446:
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs}}</nowiki></code>
	\| firstInvokeArg		\| ''firstInvokeArg''
	\|-		\|-
	\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>		\| <code><nowiki>{{ExampleArgs\|firstTemplateArg}}</nowiki></code>

Explorer09: /* Wrappers */ Behaviors of frameOnly and parentOnly in relations with wrapper templates. (This documentation is not good enough; can be improved later.)

2024-11-18T09:33:18Z

Wrappers: Behaviors of frameOnly and parentOnly in relations with wrapper templates. (This documentation is not good enough; can be improved later.)

@@ Line 338: / Line 338: @@
 })
 </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.
 # 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>.

Explorer09: /* Options */ Clarify "valueFunc" on its relation to "trim" and "removeBlanks"

2024-11-17T04:28:42Z

Options: Clarify "valueFunc" on its relation to "trim" and "removeBlanks"

← Previous revision		Revision as of 04:28, 17 November 2024
Line 118:		Line 118:
	</syntaxhighlight>		</syntaxhighlight>

	~~The~~ <code>~~trim~~</code> option will ~~have~~ no ~~effect~~ ~~when~~ <code>~~valueFunc~~</code> option is ~~given~~.		When the <code>valueFunc</code> option is given, the <code>valueFunc</code> function will be responsible for trimming whitespace, and the <code>trim</code> option will have no effect.

	=== Removing blank arguments ===		=== Removing blank arguments ===
Line 130:		Line 130:
	</syntaxhighlight>		</syntaxhighlight>

	This might be necessary for some templates' operation.		This might be necessary for some templates' operation.

	Note: When converting MediaWiki templates to Lua, keep in mind that in Lua, blank strings and strings consisting only of whitespace are considered true. If you don't pay attention to such blank arguments when you write your Lua modules, you might treat something as true that should actually be treated as false.		Note: When converting MediaWiki templates to Lua, keep in mind that in Lua, blank strings and strings consisting only of whitespace are considered true. If you don't pay attention to such blank arguments when you write your Lua modules, you might treat something as true that should actually be treated as false.

	~~The~~ <code>~~removeBlanks~~</code> option will ~~have~~ no ~~effect~~ ~~when~~ <code>~~valueFunc~~</code> option is ~~given~~.		When the <code>valueFunc</code> option is given, the <code>valueFunc</code> function will be responsible for handling blank arguments, and the <code>removeBlanks</code> option will have no effect.

	=== Custom formatting of arguments ===		=== Custom formatting of arguments ===

Explorer09: /* Options */ Rewrite descriptions of "trim" and "removeBlanks" options. Focus on behavior first, then rationale, because many users don't care about the latter when they read the manual.

2024-11-16T20:49:53Z

Options: Rewrite descriptions of "trim" and "removeBlanks" options. Focus on behavior first, then rationale, because many users don't care about the latter when they read the manual.

← Previous revision		Revision as of 20:49, 16 November 2024
Line 90:		Line 90:
	trim = false,		trim = false,
	removeBlanks = false,		removeBlanks = false,

	valueFunc = function (key, value)		valueFunc = function (key, value)
	-- Code for processing one argument		-- Code for processing one argument
Line 109:		Line 108:
	</syntaxhighlight>		</syntaxhighlight>

	=== Trimming ~~and removing blanks~~ ===		=== Trimming whitespace ===

			MediaWiki trims whitespace for named arguments coming from #invoke or a template call, but preserves whitespace for positional arguments. By default, this module helps trim whitespace also for position arguments. To preserve whitespace for positional arguments, set the <code>trim</code> option to <code>false</code>.
⚫	~~Blank~~ ~~arguments often trip up coders new to~~ converting MediaWiki templates to Lua~~. In template syntax~~, ~~blank~~ ~~strings~~ ~~and~~ ~~strings consisting only of whitespace are considered false. However,~~ in Lua, blank strings and strings consisting of whitespace are considered true. ~~This means that if~~ you don't pay attention to such arguments when you write your Lua modules, you might treat something as true that should actually be treated as false~~. To avoid this, by default this module removes all blank arguments~~.

			<syntaxhighlight lang="lua">
	Similarly, whitespace can cause problems when dealing with positional arguments. Although whitespace is trimmed for named arguments coming from #invoke, it is preserved for positional arguments. Most of the time this additional whitespace is not desired, so this module trims it off by default.
			local args = getArgs(frame, {
		⚫	trim = false
			})
			</syntaxhighlight>

			The <code>trim</code> option will have no effect when <code>valueFunc</code> option is given.

			=== Removing blank arguments ===

	~~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>.		"Blank arguments" are arguments from #invoke or template that are blank strings or consist of only whitespace. By default, this module removes all blank arguments. To preserve the blank arguments, set the <code>removeBlanks</code> option to <code>false</code>.

	<syntaxhighlight lang="lua">		<syntaxhighlight lang="lua">
	local args = getArgs(frame, {		local args = getArgs(frame, {
⚫	trim = false,
	removeBlanks = false		removeBlanks = false
	})		})
	</syntaxhighlight>		</syntaxhighlight>

			This might be necessary for some templates' operation.

		⚫	Note: When converting MediaWiki templates to Lua, keep in mind that in Lua, blank strings and strings consisting only of whitespace are considered true. If you don't pay attention to such blank arguments when you write your Lua modules, you might treat something as true that should actually be treated as false.

			The <code>removeBlanks</code> option will have no effect when <code>valueFunc</code> option is given.

	=== Custom formatting of arguments ===		=== Custom formatting of arguments ===

Explorer09: /* Wrappers */ "set to false", not "set to 0", as Lua evaluates 0 to true.

2024-11-16T19:39:25Z

Wrappers: "set to false", not "set to 0", as Lua evaluates 0 to true.

← Previous revision		Revision as of 19:39, 16 November 2024
Line 329:		Line 329:
	Notes:		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 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 0 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.		# 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.
	# 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>.		# 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>.