Last modified: 2013-03-13 10:41:44 UTC
Related to bug 15704 and to piped passed parameters. Also related to templates using meta-templates. Imagine a template {{main}} with a parameter {{{article}}} that may optionally be defined by user. If not, it should be defaulted to {{PAGENAME}}. Say template {{main}} repeatedly calls for template {{core}} a number of times. And say template {{core}} needs to receive the value of 'article', among other parameters. Template {{{core}}} could easily process {{PAGENAME}} (or any other defaulted value) by its own. What it really needs is to know if {{{article}}} is actually defined or not. We currently manage two ways to work around this situation: 1. By means of *repeatedly* passing |article={{{article|{{PAGENAME}}}}} from main to core, with core using {{{article}}} as is. 2. Passing |article={{{article|}}} with core *repeatedly* asking {{#if:{{{article|}}}|{{{article}}}|{{PAGENAME}} }} Well I suggest that, at parsing time, all defined named parameters (except number-named ones) in main template call (ie parameters existing in wikitext tag) be passed "as they are" to all nested templates. Of course, any re-defined parameter by main template code should override this pass-through condition. Number-named parameters should be kept apart of this treatment. This enhancement will permit to obviate unnecessary re-definitions at 'main template' side and conditional #ifs at 'core' side. While parameters not expected by sub-called 'core' or 'meta' templates will be ignored. As non-defined parameters will not be passed, and main template will not re-transmit them by code, then core template will not see them at all. Backward compatibility is almost complete, except for rare occurrences of equally-named parameters which may cause malfunctions. But these cases may easily be addressed.
In brief: at parsing time, all named parameters defined in a wikitext tag, should be virtually inserted at the beginning of all template tags encountered in the target template code. 'At the beginning' condition permits the template real tags to override virtually attached parameters. Just an example. Actual page tag: {{main |Foo |article=My Title |bar=Bar |2=some text |unnamed |flag=yes }} Current 'main' template content: {{core |{{{1}}} |text={{{2}}} |article={{{article|}}} |flag={{{flag|no}}} |style=normal}} Simplified content after suggested enhancement: {{core |{{{1}}} |text={{{2}}} |style=normal}} Virtual call at parsing time: {{core |article=My Title |bar=Bar |flag=yes |{{{1}}} |text={{{2}}} |style=normal}} Current 'core' template content: *Title is {{#if:{{{article|}}}|{{{article}}}|{{PAGENAME}} }} *Any process comprising {{{1}}}, {{{text}}}, {{{flag}}} and {{{style}}} Simplified content after suggested enhancement: *Title is {{{article|{{PAGENAME}}}}} *Any process comprising {{{1}}}, {{{text}}}, {{{flag}}} and {{{style}}} Note that in case of page tag includes a parameter |style=very big and colorful it will be over writen by main template
I'd strongly recommend WONTFIX; templates are complicated enough, and this adds immensely to the number of possible things that can and will go wrong. Many parameter names are very common, and passing them down from one template to another would create unexpected, hard-to-resolve conflicts.
I've seriously meditated about that. A very simple solution to achieve backward compatibility may be a magic word __PASSPARAMETERS__ to be included in templates once they've been checked for this behavior. Thus, the suggested enhancement will only be activated in templates containing that magic word. Templates and subroutines complexity could be significantly simplified, and expansion depth reduced, by means of this method. Furthermore, I think users can adapt themselves easily to this intuitive behavior, that will conduce to more clean template structures.
I actually had some really nice code for a parserfunction that could make a template call and passthru arguments, never finished the ext but I should still have the code.
A one-per-time function like {{#passparam:parametername}} may be an alternative to be used in tags for selected parameters. Thus, the difference between {{core |foo={{{foo|}}} }} and {{core |{{#passparam:foo}} }} should be that the former does not pass the 'undefined' condition of parameter foo to template core, while the later does.
A simpler syntax for the per-parameter alternative: {{core |foo = {{{bar}}} }} //without pipes! Where parser should translate this no-piped syntax as: "If {{{bar}}} is defined, pass its value to template 'core' as parameter 'foo'; if it is not defined, do not pass anything, so making template 'core' can evaluate {{{foo}}} as undefined." Thus, sub-template 'core' can default {{{foo}}} to {{{foo|something}}}
