Module talk:Template wrapper

using positional parameters[edit]

This module was initially written so that positional parameters in the wrapper template are not passed on to the working template. That's fine for templates like the cs1|2 templates because they do not use positional parameters but is problematic for templates like {{ERIC}} which wraps {{Catalog_lookup_link}}.

So I've invented a new parameter for Module:template wrapper: |_pass-all= which when set to yes in the module {{#invoke:}} causes the module to pass all wrapper-template parameters except those listed in |_exclude= to the working template. Here is {{ERIC/sandbox}} which uses Module:template wrapper/sandbox with |_pass-all=yes to wrap {{Catalog_lookup_link/sandbox}} which invokes Module:Catalog_lookup_link/sandbox:

{{ERIC/sandbox|ED046562|EJ671671|url-access=free}}

ERIC ED046562, EJ671671

Here is {{EFloras/sandbox2}} which uses Module:template wrapper/sandbox without |_pass-all= to wrap {{cite web}} which invokes Module:Citation/CS1. Positional parameters are used by {{EFloras}} and not passed to {{cite web}}:

{{EFloras/sandbox2|1|233501007|Quercus alba |volume=3 |first=Kevin C. |last=Nixon | access-date = 18 August 2018 }}

Nixon, Kevin C. (1997). "Quercus alba". Flora of North America North of Mexico (FNA). Vol. 3. New York and Oxford. Retrieved 18 August 2018 – via eFloras.org, Missouri Botanical Garden, St. Louis, MO & Harvard University Herbaria, Cambridge, MA. {{citation}}: External link in |via= (help); Unknown parameter |editors= ignored (|editor= suggested) (help)CS1 maint: location missing publisher (link)

Compare the live {{Efloras}}:

{{EFloras|1|233501007|Quercus alba |volume=3 |first=Kevin C. |last=Nixon | access-date = 18 August 2018 }}

Nixon, Kevin C. (1997). "Quercus alba". In Flora of North America Editorial Committee (ed.). Flora of North America North of Mexico (FNA). Vol. 3. New York and Oxford: Oxford University Press. Retrieved 18 August 2018 – via eFloras.org, Missouri Botanical Garden, St. Louis, MO & Harvard University Herbaria, Cambridge, MA.

What have I missed?

—Trappist the monk (talk) 11:29, 19 August 2018 (UTC)[reply]

Unless I'm misunderstanding something, the below looks like it will add all the positional pframe_args regardless of |_exclude= or unset.

	if pass_all then
		for i, v in ipairs (pframe_args) do
			add_parameter (i, v, args, list);
		end
	end

I think the below would do what you intend.

local function pframe_args_get (pframe_args, args, exclude, pass_all, list)
	for k, v in pairs (pframe_args) do
		if (pass_all or type (k) ~= 'number') and not is_in_table (exclude, k) then	-- do not pass along excluded parameters
			if v and ('' ~= v) then													-- pass along only those parameters that have assigned values
				if 'unset' == v:lower() then										-- special keyword to unset 'default' parameters set in the wrapper template
					v = '';															-- unset the value in the args table
				end
				add_parameter (k, v, args, list)									-- add all other parameters to args in the style dictated by list
			end
		end
	end
end

It might make more sense to use |_pass_positional= instead of |_pass-all= since |_exclude= still applies. frame_args_get should also be adjusted so that the new parameter isn't passed. — JJMC89 (T·C) 18:11, 19 August 2018 (UTC)[reply]

I did not intend that positional parameters should be excludable. Perhaps they could be but how is that properly handled? If we pass {{{1}}} and exclude {{{2}}} what do we do with {{{3}}} et seq.? Does {{{3}}} become the new {{{2}}}? I just didn't want to venture along that cow track until there is a demonstrated need to go there.

I didn't consider the possibility of a positional parameter having the unset value. I'll fix that.

Using ipairs() as I did ensures that empty positional parameters are passed along to the working template. In the pairs() version, the if v and ('' ~= v) then prevents empty positional parameters from being added to the args table.

I overlooked adding |_pass-all= to frame_args_get(); I'll do that. As you can see I was not very successful in finding a good parameter name. |_pass-all= is the shortest I could come up with and was, I felt, marginally better than |_pass-positional= which I felt implied 'only' but was shorter than |_include-positional= which was the best in terms of describing what it does at the expense of length; I was hoping for a single word but was unable to find one that is suitable. I'll change to |_include-positional=.

—Trappist the monk (talk) 21:29, 19 August 2018 (UTC)[reply]

I misunderstood your comment in the module then. Let's not let positional parameters be excluded with |_include-positional=; I agree it would be difficult to properly handle. I made this edit. I think the sandbox looks good now. — JJMC89 (T·C) 21:53, 19 August 2018 (UTC)[reply]

Yeah, we edit conflicted over that. I've updated the live module.

—Trappist the monk (talk) 22:36, 19 August 2018 (UTC)[reply]

@Trappist the monk: Potentially a dumb question, but is there a way to pass all but one positional parameter? I tried a bunch of ways to exclude positional parameter "1" in Template:Multiref2/sandbox before reading this discussion. If there's not a clean solution, I'll leave it as is. Rjjiii (talk) 02:39, 12 July 2023 (UTC)[reply]

I don't think so. But why would you want to? Positional parameters have meaning so suppressing {{{1}}} in the call to the working template 'bumps' the subsequent positional parameters: wrapper template {{{2}}} becomes working template {{{1}}} and so on. For {{multiref2}} that doesn't much matter but for other templates it can make a hash of things.

I think that you will need to make a very strong case for a modification to this module.

—Trappist the monk (talk) 13:07, 12 July 2023 (UTC)[reply]

Gotcha, I'm not asking for a modification, just making sure that I understand how the module works. Rjjiii (talk) 19:20, 12 July 2023 (UTC)[reply]

An additional follow-up: On second thought, it made more sense to style the first positional reference rather than filter it out. Disregard my confusion above. Rjjiii (talk) 06:48, 16 July 2023 (UTC)[reply]

support for aliasing and parameter name reuse;[edit]

I have added code so that the wrapper templates can support parameter aliasing and same-name reuse. Also updated the documentation. Existing applications should not notice the change. But, famous last words, those, report anomalies here.

—Trappist the monk (talk) 13:46, 17 November 2018 (UTC)[reply]

_substall[edit]

@Pppery: If you are going to make changes to this module, please document those changes both in the code and in the doc page.

Please explain this:

if mw.isSubsting() and frame.args._substall == "no" then
	return require("Module:Template invocation").invocation(template, args)
else
	return frame:expandTemplate {title=template, args=args};				-- render the working template
end

How is the one different from the other?

—Trappist the monk (talk) 19:09, 19 February 2019 (UTC)[reply]

One of those actually transcludes the template, whereas the other one returns a wikitext version of the template. The purpose of that edit was, as I explained in the edit summary, to make this module easier to use for substituted templates. To demonstrate this, support you have a template {{X1}}, which contains the code {{#invoke:Template wrapper|wrap|_template=X2|xxx=yyy|_substall={{{_substall}}}|_exclude=_substall}}. If |_substall=no is specified, then substing Template:X1 will produce a transclusion of Template:X2, as opposed to a substitution of Template:X2 which is produced without the _substall param. {{3x|p}}ery (talk) 19:14, 19 February 2019 (UTC)[reply]

@Pppery: If you are going to make changes to this module, please document those changes both in the code and in the doc page.

—Trappist the monk (talk) 15:59, 22 February 2019 (UTC)[reply]

A substitute option would indeed be really useful. I see your edit summary when you reverted. Are these problems surmountable? — Martin (MSGJ · talk) 12:32, 8 February 2024 (UTC)[reply]