Module talk:Template wrapper

using positional parameters

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;

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

@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]